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Abstract 

Today,  Remotely-Piloted  Aircraft  (RPA)  provide  users  with  unique  mission 
capabilities,  particularly  on-demand  overhead  surveillance.  However,  a  capability  gap 
has  been  identified  between  the  range  and  endurance  of  RPAs  powered  by  internal 
combustion  engines  (ICE)  and  the  reduced  acoustic  signature  and  smaller  logistical 
footprint  associated  with  electric-powered  RPAs.  This  research,  sponsored  by  the  Office 
of  the  Secretary  of  Defense,  aims  at  advancing  systems  engineering  education  by 
evaluating  the  utility  of  a  tailored  systems  engineering  approach.  The  tailored  systems 
engineering  approach  used  herein  focuses  on  conducting  a  concept  evaluation  study  on 
the  rapid  prototype  development  of  a  parallel  hybrid-electric  RPA  (HE -RPA)  and  its 
ability  to  fill  an  identified  mission  capability  gap.  The  concept  evaluation  utilizes  a 
tailored  systems  engineering  process  to  conduct  a  rapid  prototype  development  and 
system  evaluation.  Two  prototype  RPAs  and  a  support  system  are  designed,  integrated, 
and  tested  within  a  13  month  time  window,  in  accordance  with  an  established 
architectural  framework.  The  integration  of  a  parallel  hybrid-electric  system  into  an  RPA 
demonstrated  a  potential  reduction  in  acoustic  signature  and  improves  endurance  over 
electric  powered  RPAs;  however,  immature  technology  and  added  system  complexity 
result  in  overall  perfonnance  that  is  currently  on  par  with  ICE-powered  RPAs  and  only 
partially  satisfies  the  capability  gap. 
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I.  Introduction 


1.1.  Background 

Unmanned  aerial  systems  (UASs)  and  the  capabilities  they  provide  have  emerged 
as  one  of  the  most  “in  demand”  capabilities  the  USAF  provides  the  Joint  Force  [1], 

These  unmanned  systems  are  valued  by  combatant  commanders  (COCOMS)  for  their 
versatility  and  persistence  [2].  Throughout  the  past  decade,  the  Department  of  Defense 
has  relied  heavily  upon  remotely-piloted  aircraft  (RPA),  also  referred  to  as  unmanned 
aerial  vehicles  (UAV),  to  perfonn  a  majority  of  intelligence,  surveillance,  reconnaissance 
(ISR)  missions.  RPA’s  have  made  significant  contributions  to  the  Global  War  on  Terror 
(GWOT)  including  the  locating,  monitoring,  and  neutralizing  of  enemy  combatants, 
identification  of  and  detonation  of  improvised  explosive  devices  (IED),  and  the  collection 
of  signals  intelligence  (SIGINT).  By  2008,  RPAs  (excluding  hand-launched  platfonns) 
had  flown  almost  500,000  flight  hours  in  support  of  Operation  Enduring  Freedom  (OEF) 
and  Operation  Iraqi  Freedom  (OIF).  The  hand-launched  RQ-1 1  Raven  had  flown  in 
excess  of  1 10,000  flight  hours  supporting  deployed  forces  [2]. 

Remotely-piloted  aircraft  not  only  provide  information  to  senior  decision  makers, 
but  also  to  Joint  and  Coalition  forces  operating  in  the  field.  In  order  to  effectively 
perfonn  persistent  ISR  “stare”  missions  [2],  RPAs  must  gather  data  for  prolonged  periods 
of  time  without  being  discovered.  Due  to  the  high  energy  density  of  fossil  fuels,  mid¬ 
endurance  (4-12  hrs)  and  long-endurance  RPAs  (12+  hrs)  typically  have  internal 
combustion  (IC)  engines.  The  problem  with  IC  engines  has  been  that  they  generate 
excessive  noise,  limiting  the  proximity  of  the  ISR  gathering  RPA  to  the  area  of  interest. 
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Mid-endurance  and  long-endurance  RPAs  powered  with  IC  engines  typically 
operate  within  a  range  (typically  high  altitude)  necessitating  the  use  of  costly  optics  and 
sensors  for  ISR  data  collection.  These  features  preclude  long  endurance  RPAs  from  being 
operated  by  field  level  units  in  austere  environments  with  limited  logistical  support. 

These  costly  features  also  limit  RPA  availability,  restricting  their  use  to  the  highest 
priority  missions.  The  primary  goal  of  the  United  States  Department  of  Defense  (DoD) 
Unmanned  Systems  Integrated  Roadmap  FY2009-2034  is  to  propose  feasible  means  to 
capitalize  on  unmanned  technologies  in  order  to  allow  the  warfighter  to  conduct  more 
missions  effectively  with  less  risk.  Included  within  this  goal  is  the  development  and 
procurement  of  systems  capable  of  carrying  out  missions  in  a  covert  manner,  which,  until 
recently,  has  received  minimal  emphasis  [2,  3],  Reductions  in  both  the  acoustic  and 
thennal  signatures  of  RPAs  will  facilitate  attainment  of  these  goals  and  may  pave  the  way 
for  field  and/or  forward  deployed  units  to  access  the  benefits  of  the  mid  to  long 
endurance  RPAs. 

1,2.  Motivation 

The  push  for  advancements  in  UAS  and  RPA  technology  and  increased 
procurements  is  driven  by  the  desire  to  keep  unmanned  systems  on  pace  with  mission 
demands  to  support  the  GWOT  [2,  3],  The  evolution  of  US  fighting  forces  over  the  last 
decade  has  resulted  in  the  creation  and  utilization  of  smaller  more  agile  special  operations 
teams  often  operating  within  hostile  and  arduous  terrain.  Given  the  extreme  mobility 
requirements  of  these  forces  in  regions  such  as  the  mountains  of  Afghanistan  and 
Pakistan,  or  the  complex  urban  sprawl  of  Baghdad,  the  size  and  weight  of  their 
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equipment  is  a  critical  factor  [4],  These  special  operations  forces  need  to  balance  their 
desire  to  make  units  smaller  with  their  desire  to  have  the  covert  and/or  standoff  ISR 
capabilities  UAS  provide.  A  tradeoff  needs  to  be  made  between  the  mobility  of  their 
units  and  the  capability  of  their  systems. 

Due  to  the  quantity  and  dispersed  nature  of  special  operation  taskings,  utilizing 
high-value  low-density  UAS  and  RPAs  with  large  logistical  footprints  (often  approaching 
that  of  manned  aircraft),  such  as  the  long  endurance  MQ-1  Predator,  MQ-9  Reaper,  or 
RQ-4  Global  Hawk,  is  not  feasible  in  most  situations.  In  an  effort  to  reduce  the  logistical 
footprint,  yet  maintain  the  desired  persistent  ISR  capabilities,  several  smaller  UAS  (hence 
referred  to  as  RPA’s)  such  as  the  Aerosonde  Mark  4.7  UAV,  the  Boeing  ScanEagle,  and 
the  Northrup  Grumman  MQ-5B  Hunter  have  been  introduced  [5,  6,  7].  While  these 
systems  are  capable  of  delivering  the  desired  persistent  ISR  to  field  level  units,  they  still 
require  a  level  of  logistical  support  rendering  them  impractical  for  use  by  highly  mobile 
units.  Additionally,  they  are  powered  by  IC  engines,  precluding  their  use  as  a  covert  (or 
low  observable)  ISR  collection  platfonn,  especially  for  the  utilization  of  payloads 
optimized  for  lower  altitudes.  Although  significantly  cheaper  than  the  more  advance 
MQ-1,  MQ-9,  and  RQ-4,  the  cost  of  these  systems  still  precludes  them  from  widespread 
use. 

UAS  and  RPAs  are  now  so  entrenched  and  valued  in  military  operations,  that 
once  routine,  albeit  hazardous,  missions  are  sometimes  cancelled  unless  they  have 
support  from  an  RPA.  Ultimately,  special  operations  and  field  level  forces  need  a 
persistent  ISR  capability  that  would  allow  them  to  attain  the  capabilities  of  the  more 
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logistically  demanding  and  more  expensive  systems.  The  need  for  such  a  system  has  not 
gone  unnoticed.  In  2003,  both  the  Defense  Science  Board  and  the  US  Air  Force 
Scientific  Advisory  Board  added  a  small  (less  than  50  lbs),  low-observable  (near-silent) 
RPA  to  their  lists  of  recommended  capabilities  [1],  In  an  effort  to  address  this  need  for  a 
small,  near-silent,  RPA  with  the  desired  persistent  ISR  capabilities,  in  conjunction  with 
the  goals  set  forth  in  the  DoD’s  Unmanned  Systems  Integrated  Roadmap  FY2009-2034  , 
this  research  involves  the  development  and  evaluation  of  an  RPA  powered  by  emerging 
hybrid-electric  (HE)  technology. 

1.3.  Problem  Description 

Currently,  an  RPA  platform  possessing  the  desired  endurance  and  near-silent 
operation  capabilities  needed  for  remote,  longer  duration,  missions  does  not  exist.  As 
mentioned  above,  vehicles  such  as  the  Aerosonde  Mark  4.7,  the  Boeing  ScanEagle,  and 
the  Northrop  Grumman  MQ-5B  Hunter  possess  the  desired  endurance,  but  are  larger  and 
lack  the  desired  near-silent  operation.  Electric,  battery  powered,  vehicles  such  as  the 
AeroVironment  RQ-1 1  Raven  have  been  used  extensively  due  to  their  man-portable 
nature  and  their  ability  to  fly  over  target  areas  relatively  unnoticed.  They  are  powered  by 
a  small  electric  motor  allowing  them  to  fly  considerably  lower,  making  them  ideal  for 
payloads  optimized  at  lower  altitudes.  However,  electric  powered  RPAs  such  as  the  RQ- 
1 1  Raven  do  not  possess  substantial  endurance  due  to  the  lower  specific  energy  levels  of 
the  required  batteries,  with  typical  flight  times  of  60-90  min  [8]. 

The  US  Air  Force  is  exploring  the  potential  of  alternative  power  sources  in  order 
to  expand  the  capabilities  of  RPA  platforms.  Previous  research  in  this  area  has  resulted 


4 


in  a  concept  for  a  small,  HE-RPA.  The  concept  entails  the  design  and  fabrication  of  an 
RPA  possessing  both  the  endurance  and  range  capabilities  of  RPAs  powered  by  an 
internal  combustion  engine  (ICE),  and  the  reduced  acoustic  signature  and  smaller 
logistical  footprint  associated  with  electric-powered  RPAs.  The  envisioned  concept  will 
consist  of  an  RPA  powered  by  an  HE  propulsion  system  (HEPS),  integrated  into  an  RPA 
airframe  optimized  for  the  HEPS.  A  concept  such  as  this  has  yet  to  be  demonstrated  as  a 
viable  option  for  enhancing  the  US  Air  Force’s  RPA  capabilities. 

Given  that  the  demand  for  RPA  capabilities  will  continue  to  grow  at  astounding 
rates,  there  exists  an  attended  need  for  the  DoD’s  acquisition  workforce  to  quickly 
acquire  and  develop  weapon  systems  in  response  to  rapidly  changing  threats  [9].  Good 
systems  engineering  is  vital  to  a  successful  acquisition  program  and  hence  the  fielding  of 
the  desired  capabilities.  However,  the  accumulation  of  systems  engineering  and 
management  processes  and  controls  over  the  years  is  believed  to  have  hindered  the  ability 
of  the  acquisition  workforce  to  deliver  systems  and  capabilities  in  a  timely  manner  [9]. 

In  2007,  at  the  request  of  the  Deputy  Assistant  Secretary  of  the  Air  Force,  the  National 
Academy  of  Science  (NAS)  conducted  a  study  to  examine  the  role  that  systems 
engineering  play  in  the  defense  acquisition  lifecycle.  One  of  the  key  recommendations 
made  by  the  NAS,  was  to  use  a  systems  engineering  process  specifically  tailored  to  the 
application  in  lieu  of  the  rigidly  evolved  process  currently  used  today  [9] .  In  order  to 
capitalize  on  the  rapid  growth  in  RPA  technology,  such  as  the  aforementioned  HE 
technology,  and  to  get  these  systems  and  their  capabilities  into  the  hands  of  the 
warfighter,  a  tailored  systems  engineering  approach  needs  to  be  explored  for  small  HE- 
RPA  procurement. 
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1.4.  Research  Objectives 


The  purpose  of  this  research  was  to  utilize  a  tailored  systems  engineering 
approach  to  develop  and  evaluate  a  hybrid-electric  (HE)  RPA  prototype  against  a  concept 
of  operations  (CONOPS),  within  an  accelerated  13  month  time  window.  The  RPA 
prototype  was  to  be  tested  and  evaluated  in  a  fully  integrated  system.  At  a  more  discrete 
level,  the  effort  would  detennine: 

•  If  current  HE  technology  exists  as  a  viable  option  for  a  small  RPA; 

•  If  an  airframe  optimized  for  an  HEPS  system  is  airworthy; 

•  If  an  HE  control  strategy  can  be  developed  and  implemented  into  an  RPA; 

•  If  an  HE  system  can  be  successfully  integrated  into  an  RPA; 

•  If  an  HEPS  improves  the  flight  endurance  of  an  RPA  over  an  RPA  equipped  with 
a  non-HE  system; 

•  If  the  HE  system  results  in  a  reduced  acoustic  signature; 

•  If  the  HE  powered  RPA  meets  capability  requirements  set  forth  in  a  CONOPS; 

•  If  a  streamlined  systems  engineering  process  can  enhance  rapid  prototype 
development  and  demonstration. 

•  If  the  HE-RPA  system  is  a  viable  candidate  for  future  development. 

1.5.  Research  Scope 

This  effort  was  limited  to  a  13  month  time  window.  Within  this  time  period, 
previous  research  conducted  by  Harmon  et  al  [10,  11]  was  utilized  to  procure  two 
identical  airframes  and  to  develop  the  hybrid-electric  propulsion  system  and  the 
associated  control  strategy,  control  hardware,  and  control  software.  The  first  airframe 
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was  configured  with  an  ICE  and  was  utilized  to  establish  baseline  airframe  perfonnance 
characteristics  such  as  flight  endurance,  control  performance,  and  acoustic  signature.  The 
second  airframe  was  utilized  as  an  integration  and  evaluation  platfonn  for  the  HE- 
propulsion  system;  a  prototype  of  the  envisioned  concept.  System  evaluations  were  to 
consist  of  a  series  of  bench  testing,  ground  testing,  and  flight  testing  events. 

Due  to  the  13  month  time  restriction  and  an  inherent  budget  limitation,  it  was 
unrealistic  to  produce  a  production  representative  system  as  envisioned  within  the 
CONOPS.  Therefore,  a  tailored  SE  process  was  utilized  in  order  to  produce  a  prototype 
system  within  the  given  constraints.  As  a  result,  the  targeted  capabilities  for  the 
prototype  were  scaled  back  from  the  full  set  contained  in  the  CONOPS.  This 
configuration  is  referred  to  the  “as-built”  configuration.  A  fully  capable  system 
configuration  is  referred  to  as  the  “as-intended”  configuration.  The  systems  architecture 
includes  both  the  “as-built”  and  “as-intended”  configurations  in  order  to  acknowledge 
and  to  understand  the  current  deviations  from  a  fully  capable  system.  The  results  of  the 
system  evaluations  and  the  tracked  deviations  from  the  “as-intended”  configuration  were 
used  to  characterize  the  resources  and  remaining  effort  required  to  achieve  the  “as- 
intended”  configuration  of  the  RPA.  The  anticipated  capabilities  of  the  “as-intended” 
configuration  were  extrapolated  from  the  tests  accomplished  on  the  “as-built” 
configuration  of  the  RPA.  An  evaluation  of  the  tailored  systems  engineering  approach 
was  also  included  within  the  context  of  this  research. 

There  were  ongoing  parallel  efforts  and  research  associated  with  the  fabrication 
and  characterization  of  the  hybrid  propulsion  system,  RPA  flight  control  strategies,  and 
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propeller  optimization.  These  efforts  only  receive  a  cursory  discussion  when  necessary. 
Additional  information  is  available  in  Harmon  [11],  Ausserer  [12],  Giacomo  [13]  and 
Rotramel  [14]. 

1.6.  Research  Methodology 

The  research  objectives  were  divided  into  four  distinct  phases.  Phase  one 
consisted  of  early  systems  engineering  planning  and  the  development  of  a  systems 
architecture.  Phase  two  consisted  of  airframe  procurement  and  the  development  and 
fabrication  of  the  HEPS.  Phase  three  focused  on  systems  integration  and  baseline  testing. 
Finally,  phase  four  entailed  integrated  testing  and  an  overarching  concept  evaluation 
effort. 

This  investigation  utilized  a  tailored  systems  engineering  approach  in  order  to 
evaluate  the  HE-RPA  concept  within  a  13  month  time  window.  This  approach  took  into 
account  the  need  to  define  system  requirements  via  an  envisioned  CONOPS,  identify 
alternative  solutions,  design  and  development  of  a  functional  system(s),  and  the 
development  and  execution  of  evaluation  criteria.  Throughout  all  phases,  established 
systems  engineering  practices  were  used  when  and  where  they  were  deemed  appropriate. 

1.7.  Thesis  Overview 

Chapter  I  provides  This  thesis  begins  with  an  overview  and  the  motivation  for  this 
research  effort  along  with  limitations  and  objectives.  Next  is  a  background  on  the 
origination  of  the  HE-  RPA  concept,  which  leads  into  an  examination  of  the  requisite 
airframe,  propulsion  system,  and  control  system  components.  The  rationale  for  utilizing 
a  tailored  systems  engineering  approach  throughout  this  effort  is  also  covered.  Following 
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is  a  discussion  of  the  logical  progression  needed  in  order  to  mature  the  HE  concept  into  a 
functioning  prototype.  System  performance  measures  and  test  results  are  captured  and 
discussed  next.  Finally,  the  thesis  concludes  with  a  discussion  on  the  suitability  of  the 
HE-RPA  concept  as  a  means  of  providing  the  desired  persistent  ISR  capability  and  near- 
silent  operation.  Recommendations  for  possible  future  efforts  are  also  discussed. 
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II.  Background 


2.1.  Chapter  Overview 

This  chapter  begins  with  a  discussion  on  RPA  mission  gap  analysis  and  the 
motivation  and  objectives  of  the  research  effort.  Next  a  discussion  of  previous  research 
regarding  HE-RPAs  is  presented.  Finally,  a  discussion  on  using  a  tailored  systems 
engineering  process  and  the  applicability  to  a  rapid  prototype  development  effort. 

2.2.  Identification  of  RPA  Mission  Gap 

The  2011  United  States  Air  Force  Posture  Statement  [15]  stated  that  the  US  Air 
Force  currently  has  more  than  90  percent  of  all  available  ISR  assets  deployed.  In  an 
effort  to  relieve  the  operational  strain  on  existing  assets,  the  US  Air  Force  also  stated  that 
it  planned  to  expend  $8.2  billion  (FY 12)  on  expanding  and  supporting  ISR  capabilities. 
This  included  an  increase  in  MQ-9  Reaper  production  to  48  per  year.  Providing  ISR 
capability  to  the  Joint  Force  remains  a  chief  priority  of  the  US  Air  Force. 

While  the  US  Air  Force  is  actively  pursuing  procurement  and  sustainment  of  its 
medium  RPAs  as  noted  above  (procurement  of  RQ-4  Global  Hawk  Block  40  was 
canceled  just  prior  to  completion  of  this  document),  it  is  also  laying  out  guidelines  for  the 
future  utilization  of  Small  Unmanned  Aircraft  Systems  (SUAS),  hence  referred  to  as 
small  RPAs.  The  US  Air  Force  UAS  Flight  Plan  2009-2047  [1]  identified  a  need  to 
pursue  multi-mission  small  RPAs;  aircraft  that  close  the  gap  between  man-portable  and 
Predator  and/or  Reaper  (MQ-1/9)  capabilities.  The  focus  here  is  on  single  systems  that 
can  achieve  multiple  effects/capabilities  at  a  tactical  level.  Figure  1  from  [1]  further 
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illustrates  this  gap.  The  gray  columns  in  Figure  1  indicate  USAF  aircraft  mission  gaps 
and  the  red  highlights  emphasize  the  specific  RPA  gaps  addressed  herein. 
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Figure  1:  Planned  RPA  Capabilities,  USAF  [1] 


A  similar  need  was  identified  in  a  2009  briefing  by  the  US  Army  UAS  Center  of 
Excellence  [16].  This  briefing  identified  the  US  Army’s  need  for  RPAs  with  the 
following  capabilities: 

•  Provide  full  motion  video  (FMV)  to  soldiers  on  the  move; 

•  Increase  Tactical  Commander  situational  awareness  (SA); 

•  Provide  RPA  products  at  multiple  levels; 

•  RPAs  with  multiple  configurations  for  tactical  flexibility. 
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In  addition,  Brigadier  General  Edward  M.  Reeder  Jr.,  Commander  US  Army 
Special  Forces  Command,  stated  that  many  of  the  units  under  his  command  were  asking 
for  better,  smaller,  multipurpose  RPA  systems.  Many  of  the  units  purchased  the  Silver 
Fox  for  its  mission  endurance  and  relatively  small  logistical  footprint  [17].  The  US 
Army’s  RPA  capability  gaps  essentially  mirror  those  of  the  US  Air  Force. 

While  examining  RPA  requirements  development,  Patterson  and  Brescia  [18] 
identified  an  additional  desire  for  naval  units  to  increase  the  flight  duration  of  small 
RPAs  to  8-10  hrs,  include  automatic  engine  start,  and  add  onboard  power  generation  [18]. 
Included  below  in  Table  1  is  a  non-exhaustive  list  of  current  DoD  RPA  platforms  and 
their  primary  characteristics.  Of  note,  there  currently  is  an  extreme  jump  in  mission 
capability  when  the  tradeoff  is  made  between  battery  powered  RPAs  and  fossil  fuel  ICE 
based  RPAs. 


Table  1:  DoD  RPA  Characteristics  [1,  19,  8,  6,  5,  7] 


Remotely  Piloted 
Aircraft  System 

Weight 

Wingspan 

Length 

Airspeed 

Altitude 

Endurance 

Fuel  Source 

Range 

Payload 

Armed 

RQ-4B  Global  Hawk 

32,  250  lb 

116.2  ft 

44.4  ft 

340/310  kts 

60,000  ft 

28  hr 

JP-8 

5400  nm 

3000  lb 

No 

MQ-9  Reaper 

10,500  lb 

66  ft 

26  ft 

240/120  kts 

50,000  ft 

14-20  hr 

JP-8 

1655  nm 

3750 

Yes 

MQ-1  Predator 

2250  lb 

55  ft 

27  ft 

118/70  kts 

25,000  ft 

16-24  hr 

AVGAS 

500  nm 

450  lb 

Yes 

MQ-5  Hunter 

1950  lb 

34  ft 

23  ft 

1 1 0/70  kts 

18,000  ft 

21  hrs 

JP-8 

200  KM 

280  lb 

Yes 

RQ-7  Shadow  200 

375  lb 

14ft 

11.3  ft 

110/60  kts 

14,000  ft 

5-6  hr 

AVGAS 

125  KM 

60  lb 

No 

Aerosonde  Mark  4.7 

38  lb 

11.8  ft 

5.7  ft 

60/50  kts 

15,000  ft 

10  hr 

Gasoline 

1000  nm 

12  lb 

No 

ScanEagle 

37.9  lb 

10.2  ft 

3.9  ft 

70/49  kts 

16,400  ft 

15  hr 

Gasoline 

60  nm 

13.2  lb 

No 

70  Ih 

7.8  ft 

4.8  ft 

iR.nnn  ft 

8  hr 

5  lb 

No 

Puma  UAV 

13  lb 

9.2  ft 

4.6  ft 

45/20  kts 

10,000  ft 

2  hr 

Battery 

10  nm 

2-4  lb 

No 

RQ-1 1  Raven 

4.2  lb 

55  in 

35  in 

26  kts 

15,000  ft 

1.5  hr 

Battery 

6  nm 

3/4  lb 

No 

There  is  multi-service  consensus  on  the  need  for  a  tactical,  flexible  and  multi¬ 
modal  ISR  RPA  system  with  greater  endurance  than  what  is  currently  available  in  battery 
powered  systems. 
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2.3.  Motivations  and  Objectives 


Small  unmanned  aircraft  systems  and  remotely-piloted  aircraft  provide  a  critical 
ISR  capability  to  the  military  warfighter.  Currently,  small  RPAs  powered  by  ICEs 
(gasoline  or  diesel)  generate  mission  compromising  acoustic  and  thermal  signatures  and 
require  taxing  logistical  support.  Small  electric-powered  RPAs  lack  the  endurance  and 
range  desired  by  warfighters  [20]. 

The  acoustic  signature  is  notable  because  the  development  of  RPAs  with  reduced 
acoustic  signatures  is  included  as  an  objective  in  the  Unmanned  Aerial  Systems 
Roadmaps  published  by  the  Office  of  the  Secretary  of  Defense  [21,3].  It  is  inferred  from 
the  OSD  reports  that  the  ability  to  ingress  and  egress  into  and  out  of  a  hostile  target  area 
with  a  small  RPA  (less  than  501bs)  propelled  by  an  ICE  with  an  electric  powered  ,  near- 
silent,  and  low  altitude  surveillance  capability  would  fill  a  significant  gap  in  current  RPA 
capabilities.  An  RPA  with  a  HE-  propulsion  system  could  provide  the  desired  military 
ISR  capability  by  combining  the  advantages  of  both  the  ICE  and  electric  power  systems. 

2.4.  Previous  Research 

Previous  HE -RPA  research  conducted  by  Harmon  et  al  [10,  1 1,  20]  and  Hiserote 
[20]  was  mostly  limited  to  analytical  investigations.  The  current  researcheffort  leveraged 
funding  provided  by  OSD  to  facilitate  systems  engineering  education.  In  order  to 
characterize  the  impact  of  using  a  tailored  systems  engineering  approach,  a  technical 
challenge  needed  to  be  identified  and  addressed.  This  proved  to  be  an  ideal  opportunity 
to  bring  together  the  technical  challenge  of  the  small  HE-RPA  concept  and  an  evaluation 
of  a  tailored  SE  approach. 
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As  defined  in  the  CONOPS,  Appendix  A,  two  key  performance  parameters  for  the 
HE-RPA  and  the  ICE  RPA  were  a  long  and  quiet  loiter.  If  a  longer  loiter  than  that  of  an 
electric  motor  (EM)  powered  RPA  was  required,  and  a  quieter  loiter  than  that  of  an  ICE 
powered  RPA  was  required,  then  an  HE-RPA  was  a  possible  solution.  The  HE-RPA  was 
designed  to  take  advantage  of  the  strengths  of  both  EM  and  ICE  powered  RPAs  by 
optimizing  the  system  based  on  the  propulsion  system  requirements  for  each  operational 
mode. 

Some  hybrid  electric  propulsion  system  (HEPS)  work  has  been  pursued  by  others 
with  the  intent  to  integrate  the  HEPS  into  an  RPA.  Koster  et  al  [22]  bench  tested  an 
HEPS  that  included  an  ICE  and  an  EM  but  did  not  include  a  propeller.  Koster  et  al  also 
incorporated  a  dual  electric  propulsion  system  into  an  RPA  designed  by  a  Daniel  Webster 
College  team  and  flew  the  RPA  for  one  flight.  Although  the  RPA  crashed  during  the  first 
flight  due  to  a  strong  wind  gust,  they  were  able  to  show  that  flying  an  RPA  with  more 
than  one  electric  propulsion  system  was  possible.  Although  Koster  et  al  raised  the  bar  by 
flying  a  hybrid  system  with  two  electric  power  sources,  an  HE-RPA  has  not  yet  been 
flown  that  uses  both  an  ICE  and  an  EM. 

Glassock  [23]  designed  an  HEPS  including  an  ICE  and  an  EM  for  the  purpose  of 
reducing  the  size  of  the  ICE  required  for  flight.  Glassock  showed  that  by  using  an  EM  to 
provide  additional  power  during  takeoff,  a  smaller  ICE  was  required;  a  5%  increase  in 
weight  for  the  EM  resulted  in  35%  more  thrust  power.  Although  Glassock  did  not 
integrate  the  HEPS  into  an  RPA  and  flight  test  the  RPA,  Glassock’ s  ground  testing 
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showed  the  potential  capability  of  an  HE-RPA,  including  the  potential  to  operate  in  an 
“acoustic”  stealth  mode  by  having  an  EM  only  mode. 


2.5.  Hybrid  Operational  Modes 

An  ideal  operational  mission  profile  was  developed  by  Harmon  and  Hiserote  [20]. 
Their  ideal  mission  profile  referred  to  as  a  “segmented  ISR  mission  profile”  is  shown  in 
Figure  2  Descriptions  for  each  phase  including  taxi,  takeoff,  and  landing  phases  are 
presented  below. 


2.5.1.  Taxi 


Taxi  does  not  require  tremendous  power  and  can  be  conducted  in  ICE  only  or  dual 


mode.  The  HE-RPA  using  less  fuel  and  battery  power  during  taxi  reserves  more  for  other 


segments  of  the  mission.  Since  not  a  lot  of  time  is  spent  in  taxi  mode,  not  a  lot  of  effort 


was  placed  on  optimizing  the  taxi  mode. 
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2.5.2.  Takeoff  and  Climb 


Takeoff  and  climb  requires  the  maximum  amount  of  power.  For  an  HE-RPA,  the 
HEPS  was  sized  to  provide  the  amount  of  power  required  for  the  RPA  to  takeoff  using 
both  the  power  provided  by  the  IC  engine  and  EM.  This  mode  is  referred  to  as  dual 
mode. 

2.5.3.  Cruise 

Once  the  aircraft  has  taken  off  and  climbed  to  altitude,  it  cruises  to  the  area  of 
interest  where  it  will  loiter.  Greiser  [24]  suggested  that  the  cruise  mode  be  accomplished 
with  only  the  ICE.  Since  fossil  fuels  are  more  energy  dense  than  battery  power,  and  since 
noise  is  primarily  a  consideration  in  loiter  mode,  cruising  in  ICE  only  mode  is  the  most 
efficient.  The  IC  engine  is  sized  for  optimal  performance  in  cruise  mode.  Mengistu  [25] 
recommended  that  a  Honda  GX25  or  similarly  sized  engine  be  used  for  the  HEPS  of  an 
optimal  HE-RPA  capable  of  long  loiter  and  quiet  operation. 

If  a  shorter  time  to  the  loiter  location  is  desired,  then  cruise  can  be  accomplished 
in  dual  mode.  This  quick  cruise  mode  trades  loiter  time  over  the  target  area  for  a  shorter 
travel  time  to  the  target  area. 

2.5.4.  Endurance/Loiter 

Based  on  currently  fielded  SUAS,  the  quietest  way  for  the  RPA  to  loiter  is  to 
loiter  using  the  EM  only  mode.  Rotramel  [14]  suggested  that  an  optimal  solution  would 
include  an  efficient  electric  motor  that  is  just  powerful  enough  to  provide  the  minimum 
torque  required  during  loiter  mode.  Rotramel  [14]  further  stated  that,  “Operating  at 
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maximum  efficiency  will  require  less  current  from  the  batteries  and  therefore  result  in 
increased  endurance.” 

2.5.5.  Regeneration/Recharge 

Although  a  persistent  loiter  mode  is  ideal,  eventually  the  batteries  will  run  low 
and  additional  loiter  time  is  not  possible  without  recharging  the  batteries.  With 
regeneration  capabilities,  the  HE-RPA  could  go  to  an  area  where  a  higher  acoustic 
signature  is  acceptable  and  operate  in  ICE  only  mode  while  recharging  the  batteries.  This 
capability  supports  a  mission  where  the  HE-RPA  only  needs  to  operate  quietly  during 
segments  of  the  flight.  Any  time  during  the  mission  profile  when  the  HE-RPA  is  in 
cruise  mode,  it  can  also  be  in  regeneration  mode.  With  regeneration  capabilities,  the  total 
loiter  time  of  the  aircraft  is  extended  beyond  the  capabilities  of  one  cycle  of  the  battery 
charge. 

2.5.6.  Land 

The  HE-RPA  is  capable  of  landing  using  the  IC  engine,  EM,  or  both.  By  having 
an  HEPS  system,  there  is  a  redundant  landing  system.  When  flying  the  RPA  powered  by 
an  IC  engine  only,  the  IC  engine  was  usually  turned  off  just  before  the  aircraft  touched 
the  ground.  The  HEPS  system  improves  the  probability  of  a  recoverable  landing  by 
including  the  EM.  In  the  event  of  an  unfavorable  landing  situation  that  arises  after  the 
ICE  is  disabled,  the  EM  could  be  used  to  power  the  RPA  for  another  landing  approach. 
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2.6.  Power  Sources 


2.6.1.  Photovoltaic  Cells 

Koster  [22]  argued  that  photovoltaic  cells  can  provide  enough  power  to  offset 
their  own  weight  but  do  not  add  any  additional  net  power.  Based  on  this  analysis,  it  was 
determined  in  the  analysis  of  alternatives  that  photovoltaic  cells  would  not  be  used  for 
the  HEPS  developed  in  this  research. 

2.6.2.  HEPS 

Rotramel  [14]  researched  different  commercially  available  power  sources  and 
used  an  optimization  routine  to  detennine  the  optimal  ICE,  EM,  and  propeller  for  use  on 
the  AFIT  HEPS.  Ausserer  [12]  researched  the  commercially  available  batteries  and 
determined  that  Lithium  Polymer  (Li-Po)  batteries  would  be  the  best  batteries  to  power 
the  EM  and  avionics  system  of  the  AFIT  HEPS. 

2.7.  AFIT  Aircraft  Design 

The  conceptual  design  for  the  airframe  was  generated  by  Harmon  [6]  and  the 
actual  design  and  build  was  completed  by  CLMax  [26]  and  designated  as  the  Condor. 
Using  an  optimization  routine,  Harmon  found  that  a  large,  high  aspect  ratio  wing  would 
be  best,  while  still  taking  into  account  other  requirements  such  as  structure,  weight,  and 
low-observability.  The  Condor  was  designed  to  have  a  high  lift  to  drag  ratio  and  be 
shaped  similar  to  a  glider  to  facilitate  long  loiter  operation.  Giacomo  [13]  outlined  the 
specific  dimensions  and  flight  characteristics  of  the  Condor  in  his  thesis.  By  designing  a 
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new  airframe  instead  of  integrating  the  HEPS  into  an  existing  airframe,  the  flight 
characteristics  of  the  new  airframe  were  tailored  to  the  HE-RPA  CONOPS. 

Although  the  Condor  was  designed  to  leverage  the  capability  of  an  HEPS,  two 
airframes  were  built  to  support  this  project.  The  first  version  of  the  Condor,  AFIT  1,  was 
to  be  powered  by  a  Honda  GX35  ICE  engine.  The  second  version  of  the  Condor,  AFIT 
2,  was  to  have  the  HEPS  with  a  Honda  GX25  ICE  engine  and  an  AXI  Motor.  AFIT  1 
acted  as  the  control  for  the  AFIT  HE-RPA  effort  and  acted  as  a  baseline  for  comparing 
long  loiter  and  near  silent  capabilities. 

2.8.  Acoustic  Measurements  and  Propellers 

Almost  all  RPAs  currently  employed  throughout  the  world  rely  on  a  propeller  and 
propulsion  system  to  generate  the  thrust  necessary  for  flight.  Propellers,  however, 
contribute  significantly  to  the  overall  acoustic  signature  of  any  propeller  driven  aircraft. 
Numerous  studies  are  underway  in  an  attempt  to  characterize  and  design  quieter 
propellers,  primarily  for  use  in  congested  or  covert  locations.  Research  by  Burger  [27] 
resulted  in  a  model  capable  of  predicting  the  performance  of  specific  propeller  design; 
however,  it  was  still  immature  and  needed  addition  validation.  In  lieu  of  a  predictive 
tool,  acoustic  testing  of  propellers  and  RPAs  in-flight  is  currently  the  alternative  used  to 
evaluate  acoustic  performance.  Testing  conducted  by  Gregorek  and  Korkan  [28] 
concluded  that  propeller  acoustic  noise  is  a  function  of  propeller  loading  and  diameter; 
with  lightly  loaded  propellers  with  smaller  diameters  yielding  a  substantial  decrease  in 
noise. 
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In  regards  to  propulsion  system  noise,  research  by  Fidler  [29]  found  that  the 
acoustic  signatures  of  comparative  ICEs  and  electric  motors  were  dependent  on  the 
throttle  setting.  At  lower  throttle  settings,  the  difference  between  an  ICE  and  an  electric 
motor  was  smaller  than  at  increased  throttle  settings.  Additional  testing  with  the  Silver 
Fox  RPA  also  yielded  specific  information  about  the  acoustic  signature  of  small  RPAs 
with  ICEs  [30],  In  general,  the  Silver  Fox  testing  validated  common  employment  tactics 
and  design  for  reduced  RPA  detection. 

2.9.  Tailored  Systems  Engineering  Process 

In  light  of  the  aggressive  scope  and  limited  timeframe  of  the  current  research,  the 
HE-RPA  development  team  detennined  early  in  the  development  process,  that  it  would 
not  be  feasible  to  accomplish  all  of  the  systems  engineering  activities  prescribed  by  the 
Department  of  Defense  SE  guide  [31]  which  encompasses  commonly  accepted  SE 
practices.  However,  the  team  agreed  that  a  tailored  systems  engineering  process  would 
be  used  to  assist  in  accomplishing  research  objectives. 

The  team  detennined  that  establishing  and  following  a  tailored  systems 
engineering  process  would  assist  in  accomplishing  research  objectives  by  maintaining  a 
level  of  systems  engineering  discipline  throughout  the  research  effort.  Humphreys  et  al. 
[32]  successfully  applied  a  tailored  systems  engineering  process  to  the  development  of  a 
ground  hardness  technology  demonstrator.  The  tailored  SE  process  established  by 
Humphreys  et  al.  [32]  focused  on  requirements  management,  where  requirements  were 
defined  early  in  the  systems  engineering  process  and  tracked  throughout  the  development 


20 


of  the  system.  Humphreys  et  al.  [32]  did  not  initially  plan  on  following  the  systems 
engineering  V-Model  but  did  eventually  use  it  and  found  it  to  be  helpful. 

Additionally,  Abbott  et  al  [33]  applied  a  tailored  systems  engineering  process  to 
the  development  of  the  fleeting  target  technology  demonstrator,  which  included  a 
functional  area  analysis,  functional  needs  analysis,  functional  solutions  analysis, 
measures  of  effectiveness,  measures  of  perfonnance  criteria,  an  integrated  architecture,  a 
concept  of  operations  with  expanded  scenario  development,  a  risk  assessment  and 
analysis  with  risk  mitigation  strategies  and  a  system  level  test  plan  to  address  risk  areas. 
The  framework  of  a  tailored  SE  process,  developed  by  Abbot  et  al  [33],  was  designed  for 
use  by  all  programs  with  a  rapid  transition  from  the  lab  to  the  program  office. 

2.10.  Summary 

This  chapter  provided  a  brief  overview  of  the  current  state  of  the  development  of 
HE-RPA’s  and  their  potential  to  fill  a  capability  gap  of  long  loiter  and  quiet  operation  in 
a  military  environment.  This  chapter  also  discussed  the  potential  of  using  a  tailored  SE 
process  to  aid  in  the  rapid  development  of  an  RPA  that  would  fill  the  existing  capability 
gap.  Following  is  the  methodology  that  guides  the  remaining  HE-RPA  development 
effort. 
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III.  Methodology 


3.1.  Chapter  Overview 

This  chapter  examines  a  methodology  and  process  for  evaluating  the  hybrid- 
electric  RPA  as  a  viable  concept  to  fill  the  identified  capability  gap  and  achieve  the 
capabilities  detailed  in  the  CONOPS  (Appendix  A).  The  chapter  mirrors  a  systems 
engineering  plan  (SEP)  operational  requirements,  a  system  level  architecture,  system 
development  and  integration,  risk  management  planning,  and  development  of  a  test  and 
evaluation  master  plan  (TEMP),  Appendix  K. 

3.2.  Operational  Requirements 

Previously,  Chapter  II  detailed  the  need  for  a  tactical,  flexible  and  multi-modal 
(ICE  and  EM)  ISR  RPA  system  with  greater  endurance  than  what  was  currently  available 
in  battery-powered  systems.  Specific  requirements  were  identified  via  the  Joint  and 
USAF  UAS  future  and  vision  statements  cited  previously,  along  with  preliminary 
discussions  with  the  Air  Force  Research  Laboratory’s  (AFRL)  Center  for  Rapid  Product 
Development  (CRPD).  The  following  requirements  are  a  synopsis  of  desired  capabilities 
and  operational  needs  currently  lacking  or  deemed  insufficient  in  operational  RPA 
systems  currently  available. 

•  Rapidly  setup  and  deploy  RPA  system  from  austere  location 

•  Quickly  ingress/egress  to/from  the  target  area  utilizing  internal 
combustion  engine 

•  Covertly  loiter  over  a  desired  target  area  using  electric  power 
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Utilize  payloads  suited  for  low  altitude  operations 


•  Monitor  ISR  data  from  safe  standoff  distance 

•  Regenerate  electrical  stores  for  sustained  surveillance  operations 

•  Provide  timely  ISR  data  for  ongoing/future  ground  operations 

These  requirements  were  directly  linked  to  the  HE-RPA  concept  within  the 
CONOPS,  whereas  the  generated  systems  architecture  attempted  to  capture  the  higher 
level,  overarching,  requirements  of  operational  users  and  stakeholders. 

3.2.1.  Concept  of  Operations 

High  level  operational  needs  are  captured  within  the  CONOPS.  In  particular, 
Hannon  and  Hiserote  [20]  envisioned  a  segmented  ISR  mission  profile  in  order  to 
provide  near-silent  electric  RPA  operations,  yet  retain  the  benefits  of  an  ICE  powered 
RPA.  The  segmented  ISR  profile  is  captured  within  the  CONOPS.  The  CONOPS  details 
a  set  of  operational  capabilities  desired  by  potential  users  employing  a  HE-RPA.  The 
CONOPS  sets  the  stage  for  an  architectural  framework  aimed  at  delivering  the 
overarching  capabilities  desired  by  the  user. 

3.3.  Systems  Architecture 

The  purpose  of  the  systems  architecture  was  to  create  a  foundation  from  which 
system  development  could  begin.  Additionally,  the  foundation  of  the  tailored  SE 
approach  utilized  herein  is  a  systems  architecture  depicting  both  an  “as-intended” 
configuration  along  with  an  “as-built”  configuration.  From  inception,  it  was  well 
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understood  that  achieving  a  system  delivering  the  envisioned  capabilities  would  be 
infeasible  given  the  realistic  schedule  and  budget  constraints.  The  authors  took  a  two 
pronged  approach  in  order  to  capture  and  analyze  this  departure;  1)  development  of  dual 
systems  architecture,  an  “as-intended”  and  “as-built”  variation,  and  2)  an  analysis  and 
evaluation  of  the  known  and  identified  capability  gaps.  The  “as-built”  variation  covered 
aspects  of  the  system  that  were  reasonably  believed  achievable  within  the  given 
constraints  of  the  effort,  and  the  “as-intended”  variation  detailed  the  envisioned  system  in 
a  fully  operational  configuration.  Deviations  between  the  “as-built”  and  the  “as- 
intended”  concepts  were  captured  within  additional  architecture  products,  i.e.  the 
Systems  View  8  (SV-8).  All  systems  architecture  products  were  in  concordance  with  the 
Department  of  Defense  Architecture  Framework  (DoDAF)  Version  2.0. 

While  the  CONOPS  captured  the  full  range  of  capabilities  and  intended  usage  of 
an  HE-RPA,  it  was  observed  by  the  authors  that  the  critical  capabilities  identified  in  the 
CONOPS  below  (with  the  exception  of  multi-mode  operation)  were  not  necessarily 
specific  to  a  HE-RPA  platform. 
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Critical  Capabilities  from  HE-RPA  CONOPS 


•  Austere  Employment  Capability 

•  Rapid  Ingress  and  Egress  Capability 

•  Sustained  Near-Silent  Loiter  Capability 

•  Effective  Multi-Mode  Operation 

•  Minimally  Complex  Operator  Interface 

•  Adaptable  ISR  Payload  Capability 

Based  on  these  critical  capabilities  identified  within  the  CONOPS,  it  was  decided 
that  the  systems  architecture  would  focus  on  the  overarching  capabilities  and  the  desired 
end  state  rather  than  a  more  detailed  system/functional  architecture.  This  sets  the 
architecting  scope  for  this  effort.  In  some  instances,  it  was  useful  to  include  specific 
aspects  of  the  HE-RPA  CONOPS  within  the  architectural  products  in  order  to  facilitate  a 
comparison  between  the  “as-intended”  and  “as-built”  configurations.  Detailed 
information  on  HE-RPA  system  functionality  and  system  interactions  (physical 
architecture)  can  be  found  in  Ausserer  [12]  and  Giacomo  [13]. 

Coinciding  with  the  tailored  systems  engineering  approach,  it  was  decided  that 
only  architecture  products  providing  decisive  information  (fit-for-purpose)  would  be 
produced.  Figure  3,  illustrates  the  selected  architecture  products  and  their  relations  and 
interactions  with  one  another.  The  diagram  also  distinguishes  between  the  “as-intended” 
and  “as-built”  configurations  of  the  HE-RPA,  which  are  addressed  in  more  detail  later  in 
this  chapter.  The  development  of  a  succinct  architecture  was  viewed  as  critical  to  the 
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development  of  the  HE-RPA  as  a  potential  part  of  the  larger  military  ISR  capability.  It 
was  anticipated  that  time  spent  on  architecture  development  early  in  the  HE-RPA 
development  process  would  save  time  later  in  the  project  by  focusing  efforts  and  limiting 
the  scope  of  the  total  project. 

«iOV-1u  ucd Overview  and  Summary  [Overview  and  Sivnmary]  / 


Figure  3:  Systems  Architecture  Products;  DoDAF  version  2.0 
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3.3.1.  All  Viewpoints 


The  All  Viewpoints  of  the  DoDAF  provide  information  that  pertains  to  the  entire 
architectural  description.  In  particular,  the  All  View  1  (AV-1)  provides  executive  level 
summary  information  and  provides  the  framework  for  the  architecting  effort.  The  AV-1 
for  the  HE-RPA  documented  this  effort’s  vision,  objectives,  goals,  plans,  activities, 
events,  conditions,  measures,  and  effects.  Additionally,  the  AV-1  served  as  a  planning 
guide  for  the  entire  effort.  The  AV-1  also  details  the  purpose  of  the  architecture,  which  is 
to  provide  a  blueprint  for  vehicle  development,  gap  analysis,  and  testing.  The  complete 
HE-RPA  AV-1  is  included  as  Appendix  B. 

3.3.2.  Operational  Viewpoints  (OV) 

The  Operational  Viewpoints  were  utilized  in  the  HE-RPA  architecture  as  a  means 
to  describe  the  tasks,  activities,  operational  elements,  and  resource  flows  needed  to 
realize  the  envisioned  operational  capabilities.  The  envisioned  operational  capabilities 
were  captured  within  an  operational  scenario  realizing  the  benefits  of  an  HE-RPA.  The 
scenario  encapsulated  many  of  the  operational  requirements  collected  and  detailed 
previously  in  Chapter  II.  This  scenario  was  the  foundation  for  architectural  development. 
A  high-level  graphic  description  of  this  scenario  was  also  depicted  in  the  Operational 
Viewpoint  1  (OV-1)  Figure  4,  which  is  discussed  in  greater  detail  in  the  CONOPS. 

The  operational  scenario  envisions  a  military  ground  unit,  with  intelligence 
indicating  a  possible  increase  of  insurgent  activity  in  a  nearby  township,  deciding  to 
evaluate  the  situation  before  proceeding  with  intervening  actions.  In  this  situation,  high- 
value  low-density  assets  (Satellite  imagery,  Global  Hawk,  or  Predator  RPA)  are 
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unavailable.  Gasoline/diesel  powered  RPAs  are  noisy  and  may  alert  the  insurgents  that 
they  are  being  observed,  but  the  quieter  electric-powered  RPAs  lack  the  range  necessary 
to  both  ingress  to  and  egress  from  the  target  area  to  collect  ISR  data.  From  a  safe,  yet 
austere,  undetectable  distance,  the  hybrid-electric  RPA  can  be  quickly  setup  and 
deployed,  flown  to  the  area  of  interest,  loiter  and  collect  ISR  with  near-silent  operation 
and  relayed  ISR  data  back  to  a  ground  station  or  field  unit,  regenerate  battery  capacity  if 
prolonged  near-silent  operation  is  required,  and  then  returned  for  redeployment. 


OV-1 :  Hybrid-Electric  RPA  Operational  Concept 


Figure  4:  Hybrid-Electric  RPA  Operational  View  (OV-1) 


The  architecture  for  the  HE-RPA  was  required  to  capture  the  flow  of  information 
and  material  between  the  different  operational  activities  or  operational  nodes  required  to 
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support  the  capabilities  identified  in  the  CONOPS.  The  Operational  View  2  (OV-2) 
captured  these  flows  as  needlines  within  the  diagram,  see  Figure  5. 

As  envisioned  within  the  CONOPS,  the  RPA  represented  one  of  the  operational 
nodes,  encompassing  multiple  activities.  It  was  clear  from  the  OV-2  that  there  was  a 
heavy  dependence  on  RPA  control  information  and  ISR  data  between  the  operator  node 
and  the  RPA  node  via  the  ground  station  node.  The  operator  node  was  also  the  means  by 
which  the  RPA’s  activities  are  translated  into  useful  products  and  infonnation  back  to 
other  operational  nodes  or  stakeholders,  of  the  system.  The  OV-2  began  to  lay  the 
foundation  for  identifying  the  required  system  functionality  and  detailed  activities 
necessary  for  the  HE-RPA  system.  The  only  HE-RPA  specific  information  flow  depicted 
was  the  HE-RPA  mode  control. 
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nO V-2 o  class  Operational  Node  Connects ity  Description  [Operational  Node  Connectivity  Description] 


j 


Figure  5:  Hybrid-Electric  RPA  OV-2 
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Almost  all  RPA  missions  are  currently  centered  on  the  collection  and 
dissemination  of  ISR  data.  In  order  to  provide  this  data  via  the  use  of  an  RPA,  the  system 
requires  a  specific  set  of  activities.  These  activities  are  captured  as  use  cases  and  indicate 
what  actions  need  to  be  accomplished  and  by  whom  or  what  aspect  of  the  system.  An 
operational  activity  model,  also  referred  to  as  a  use  case  model,  captures  these 
interactions.  A  use  case  diagram  capturing  the  activities  and  relationships  depicted  in  the 
CONOPS  is  shown  in  Figure  6. 


Figure  6:  Operational  Activity  Model  (Use  Case  Diagram) 
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The  activities  depicted  in  the  use  case  diagram  are  generally  at  a  high  level  in 
relation  to  individual  tasks  or  operations.  Subsequently,  the  lower  level  actions  are 
captured  in  textual  use  cases,  which  can  then  in-turn  be  used  to  generate  activity 
diagrams  to  isolate  specific  actions  that  must  be  performed  by  the  system.  The  textual 
use  cases  and  activity  diagrams  for  this  effort  are  captured  in  Appendix  C.  The  activities 
are  also  captured  and  are  utilized  in  the  SV-5  diagram. 

Of  note  in  the  use  case  diagram  presented  above,  the  primary  objective  of  the 
scenario  is  to  provide  ISR  data  to  the  field  units  and  Command  and  Control  actors.  The 
collect  ISR  use  case  is  left  generic,  indicating  that  the  capability  could  potentially  be 
provided  via  numerous  alternatives.  The  HE-RPA  is  not  necessarily  a  forgone 
conclusion.  The  remaining  use  cases  such  as,  Establish  Comm,  Monitor  Aircraft  Status, 
Transfer  Control,  etcetera,  and  the  associated  actors  are  currently  standard  for  traditional 
RPAs.  The  trade  space  for  alternative  solutions  other  than  an  RPA  solution  has  been 
reduced.  The  remaining  systems  engineering  activities  focus  on  evaluating  an  RPA 
system  as  a  viable  solution  to  fill  the  identified  capability  gap. 

3.3.3.  Systems  Viewpoints  (SV) 

After  identifying  the  operational  requirements  of  a  system  via  the  operational 
viewpoints,  the  Systems  Viewpoints  (SVs)  are  a  means  to  describe  systems  and 
interconnections  linking  system  resources  to  the  operational  requirements.  Beginning 
with  the  established  framework  associated  with  an  RPA  system  and  operational  activities 
previously  captured  by  the  OV-2  and  OV-5,  the  Systems  Viewpoint  1  (SV-1)  allows 
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interconnections  of  the  necessary  system  elements  to  be  identified.  The  following  system 
components,  including  human  components,  were  identified  for  the  HE-RPA  system. 


•  Aircraft  (the  HE-RPA) 

•  Ground  Control  Station 


•  Global  Positioning 
Satellite  (GPS) 


•  Operator 

•  Command  and  Control 


•  Environment 

•  Support  Crew 


Manual  Backup 


•  Field  Unit 


The  SV-1  shown  in  Figure  7  identifies  the  interactions  and  sharing  of  resources 
between  elements  of  the  RPA  system.  Attributes  of  the  RPA  and  GCS  elements  are 
shown  in  order  to  identify  where  the  HE  system  capabilities  reside,  even  though  they  are 
not  prescribed  by  DoDAF  for  an  SV-1. 


#SV-1»  composite  structure  Systems  Interface  Description  [Systems  Interface  Description] 

RPA  Control  Parameters 


Figure  7:  System  Interface  Description  (SV-1) 
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A  substantial  take  away  from  the  SV-1  is  the  inherent  responsibility  that  falls  on 
the  operator  and  GCS  elements.  Regardless  of  the  HE  aspect  of  the  system,  it  is  the 
operator  and  GCS  element  that  link  the  field  unit  element  back  to  the  RPA  element.  The 
SV-1  provides  a  stable  location  within  the  architecture  where  operational  requirements 
and  system  resources  merge,  ensuring  that  operational  requirements  remain  traceable 
throughout  system  development.  The  SV-1  also  indicates  how  the  system  may  be 
potentially  structured  due  to  the  system  resource  flows  between  the  elements.  The  SV-1 
is  a  starting  point  from  which  to  evaluate  the  “as-intended”  and  “as-built”  variations  of 
the  systems  level  architecture. 

The  SV-4,  systems  functionality  description,  details  the  necessary  functions  and 
behaviors  that  the  RPA  system  must  perform  in  order  to  provide  the  desired  capabilities. 
Specific  system  functions  of  the  HE-RPA  were  added  to  the  SV-4  in  order  to  later 
identify  relationships  with  the  operational  activities.  The  SV-4  diagrams  capture  the 
deviations  between  the  “as-intended”  and  “as-built”  variations  of  the  architecture.  As  an 
example,  the  SV-4  diagrams  for  the  “ Provide  Covert  ISR”  function,  shown  in  Figure  8 
and  Figure  9,  identifies,  via  the  red  nodes,  that  the  “as-built”  configuration  will  lack 
functionality  to  operate  in  low  light  and  to  optimize  a  flight  profile.  Successful 
development  and  testing  of  the  “as-built”  configuration  becomes  more  likely  with  the 
reduced  functionality.  Additionally,  future  development  efforts  have  a  clear 
understanding  of  what  was  and  was  not  accomplished  by  prior  efforts.  A  complete  set  of 
SV-4  diagrams  and  the  identified  functionality  gaps  between  the  “as-intended”  and  “as- 
built”  configurations  is  shown  in  Appendix  D. 
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«SV-4»  obj  Systems  Functionality  Description  [Provide  Covert  ISR] 
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Figure  8:  SV-4,  Provide  Covert  ISR  “as-intended” 
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Figure  9:  SV-4,  Provide  Covert  ISR  “as-built” 
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As  a  summary  for  the  SV-4,  the  following  functions  shown  in  Table  2  were 
prescribed  for  the  “as-intended”  variation  but  removed  from  the  “as-built”  variation. 
These  functions  were  knowingly  removed  from  the  development  effort  and  they  become 
documented  gaps  for  future  efforts.  The  remaining  functions  for  the  “as-built” 
configuration  now  become  the  focus  of  the  development  effort  and  the  focus  of  Ausserer 
[12]  and  Giacomo  [13]. 


Table  2:  Functions  Removed  from  "as-intended"  Configuration 


Functions  Removed  From  the  "as-intended"  Configuration 

Operate  in  Low  Light 

Maintain  Airframe  Integrity 

Optimize  Flight  Profile 

ATV  Transportable 

Monitor  ISR  Sensor  Status 

Launch  and  Recover  on  Un-improved  Surfaces 

Follow  Moving  Target 

Identify  Targets 

Maintain  Contact  with  Target 

Although,  the  SV-4  diagrams  identify  functionality  gaps  between  the  “as- 
intended”  and  “as-built”  configurations;  that  does  not  necessarily  translate  into  capability 
gaps.  The  SV-5  captures  relationships  between  system  functions  and  activities  to  truly 
identify  if  a  capability  gap  exists. 


The  SV-5  identifies  relationships  between  the  operational  activities  depicted  in 
the  OV-5  and  the  system  functions  captured  by  the  SV-4.  The  purpose  is  to  ensure  that 
all  system  functions  are  traced  back  to  an  operational  requirement  or  vice  versa. 
Functions  that  do  dot  trace  back  to  operational  requirements  indicate  additional 
capabilities  or  features  that  were  not  originally  desired  or  are  in  excess  of  what  is 
required.  Operational  activities  that  do  not  correspond  to  a  system  function  indicate  a 
capability  gap. 
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The  SV-5  matrices  generated  for  this  effort  are  captured  in  Appendix  E.  Two 
different  variations  were  generated  in  order  to  capture  deviations  between  the  “as- 
intended”  and  “as-built”  variations  of  the  architecture.  The  operational  activities  utilized 
to  generate  the  SV-5  were  independent  of  the  pre-conceived  HE-RPA  system;  however, 
functions  associated  with  the  HE-RPA  were  included.  The  intent  was  to  determine  if  any 
of  the  HE-RPA  specific  functions,  for  both  the  “as-intended”  and  “as-built” 
configurations,  are  traceable  back  to  a  set  of  standard  RPA  operational  activities. 


Findings  from  the  SV-5  indicate  that  both  the  “as-intended”  and  “as-built” 
configurations  of  the  HE-RPA  possess  functionality  that  is  not  necessarily  traceable  back 
to  the  operational  activities  associated  with  standard  RPA  activities.  Within  the  SV-5, 
functions  highlighted  in  red  indicate  no  traceability  back  to  the  operational  activities. 
Incidentally,  these  functions  in  red  are  also  specific  and  needed  for  by  the  HE-RPAto 
increase  endurance.  Functions  highlighted  in  yellow  indicate  weak  traceability  back  to 
the  operational  requirements,  generally  two  or  less  activities.  These  weakly  related 
functions,  summarized  in  Table  3,  may  become  good  candidates  if  system  tradeoffs 
become  necessary  in  future  development  efforts. 


Table  3:  Weakly  Related  System  Functions 


System  Functions 

HE-RPA  Only 

Convert  Power 

Utilize  Common  Fuel 

Utilize  Common  Tools 

Rapid  Airframe  Assembly 

Rapid  Deployment  &  Recovery 

Intuitive  Construction 

Minimize  Fuel  Consumption 

Spin  Generator 

X 

Store  Electrical  Power 

X 

Generate  Electricity 

X 

Interrupt  Electrical  Power  Distribution 

X 
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The  SV-5  captures  areas  in  which  the  “as-built”  configuration  would  have 
reduced  capability  compared  to  the  “as-intended”  configuration.  By  looking  at  the 
activities  affected  by  excluding  functions  from  the  “as-built”  configuration,  it  becomes 
obvious  that  there  will  be  a  substantial  deviation  from  a  fully  capable  system.  A  list  of 
the  impacted  activities  is  presented  in  Table  4.  Although  several  activities  are  affected, 
no  complete  capability  gaps  were  identified.  However,  the  reduced  capabilities  of  the 
“as-built”  configuration  would  likely  be  unacceptable  to  a  user  or  operator. 


Table  4:  Reduced  Capability  "as-built"  Configuration 


Reduced  Capability  for  "as-built"  Configuration 

Fly  in  Manual  Mode 

Monitor  Aircraft  Status 

Establish  Comm 

Operator  Initiates  Recovery 

Adjust  Flight  Profile 

Operator  Receives  &  Analyze  ISR  Data 

Collect  ISR  Data 

Process  RPA  Updates 

Command  and  Control  Acknowledgment  of  Aessage  Receipt 

Provide  Mission  Updates 

Command  and  Control  Evaluates  ISR  and  Battlespace 

Re-establish  Comm 

Command  and  Control  Generates  and  Sends  Update  Request 

Receive  RPA  Status  Update 

Command  and  Control  Receive  &  Analyze  ISR  Data 

Relay  ISR  Data 

Communicate  with  Dispersed  Personnel 

RPA  Broadcasts  Signal 

Confirm  ISR  Data  Sufficient 

RPA  Encrypts  ISR  Data 

Field  Unit  Evaluates  ISR 

RPA  Processes  Signals 

Field  Unit  Receive  &  Analyze  ISR  Data 

RPA  Transmits  Status 

Field  Unit  Generates  and  Sends  Update  Request 

Support  Crew  Activates  RPA 

Launch/Recover  Aircraft 

Support  Crew  Initiates  Recovery 

Maintain  RPA  Flight  Profile 

Support  Crew  Launches  RPA 

In  order  to  progress  from  the  “as-built”  configuration  to  the  “as-intended” 
configuration,  a  high  level  mapping  of  required  effort  was  created  and  captured  in  the 
Systems  Evolution  Diagram  in  service  viewpoint  8  (SV-8).  The  SV-8  is  presented  in 
Appendix  F.  This  diagram  not  only  illustrates  remaining  effort  expected  to  achieve  the 
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“as-intended”  configuration,  but  it  was  created  early  in  this  effort  and  guided 
development  of  the  “as-built”  configuration.  Although  Appendix  F  is  a  large  diagram, 
the  page  split  represents  the  current  status  of  this  effort.  As  shown,  the  remaining  efforts 
would  likely  focus  on  system  analysis  and  refinement,  production,  and  operational 
verification.  Coinciding  with  the  planning  of  future  development  efforts,  the  SV-9 
(Technology  &  Skills  Forecast)  could  be  used  to  identify  emerging  or  existing  technology 
and  skill  that  would  aid  in  realizing  the  “as-intended”  configuration.  An  SV-9  is 
presented  in  Appendix  G.  Continued  development  of  the  “as-intended”  configuration 
may  benefit  from  emerging  battery  technology,  RPA  microcontrollers,  and  RPA 
construction  materials  as  indicated  by  the  SV-9. 

Although  the  systems  architecture  establishes  a  roadmap  for  the  development 
effort,  realization  of  the  HE -RPA  system  still  requires  robust  systems  engineering  and 
planning.  The  next  section  discusses  the  rationale  and  methods  used  for  the  remainder  of 
this  effort. 

3.4.  Early  Systems  Engineering  and  Planning 

The  initial  step  of  any  well  planned  systems  engineering  effort  should  be  the 
identification  and  definition  of  project  requirements  and  objectives;  including 
establishing  systems  architecture.  For  this  effort,  the  overarching  requirements  and 
objectives  were  the  collection  of  sufficient  infonnation  to  inform  a  decision  maker  on 
future  development  potential.  After  requirements  and  objectives  had  been  identified, 
technical  requirements  developed  via  the  systems  architecture  and  operational 
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requirements  were  developed  in  conjunction  with  the  associated  planning  efforts  needed 
to  evaluate  technical  requirements. 

In  conjunction  with  the  previously  stated  research  objectives,  this  effort’s 
emphasis  was  on  concept  evaluation  of  a  HE-RPA  and  the  desire  to  answer  pertinent 
questions  needed  to  make  a  decision  on  pursuing  further  system  development  and 
potentially  initiating  an  acquisition  program.  The  following  questions,  captured  in  the 
All- View  1  (AV-1)  of  the  systems  architecture,  were  a  focus  of  the  systems  engineering 
effort. 

•  What  additional  efforts  are  needed  to  get  to  the  “as  intended” 
configuration? 

•  What  are  the  technology  gaps? 

•  How  effective  will  it  be? 

•  Will  it  provide  military  utility? 

•  Who  are  the  users  and  stakeholders? 

•  Where  could  this  concept  be  used  successfully? 

In  order  to  answer  these  questions  within  the  inherent  time,  budget,  and  schedule 
constraints,  an  approach  examining  only  the  necessary  and  value-added  components  of 
the  traditional  SE  approach  and  DoD  acquisition  process  was  planned.  Rationale  for  the 
selection  and  utilization  of  specific  systems  engineering  and  DoD  acquisition  components 
is  discussed  below. 
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3.5.  Tailored  Systems  Engineering  Approach 


In  order  to  gather  the  information  needed  to  answer  the  previously  posed 
questions  and  to  address  research  objectives,  a  tailored  SE  approach  was  proposed.  As 
the  scope  of  the  effort  was  limited  to  the  evaluation  of  a  prototype  HE-RPA,  the  SE 
efforts  focused  on  pre-systems  acquisition  events.  The  Defense  Acquisition  Guidebook 
(DAG)  [34]  provides  a  framework  that  allows  acquisition  professionals  to  develop  and 
procure  systems  for  the  Defense  Department  in  accordance  with  DoD  directives.  The 
DAG  addresses  these  pre-acquisition  events  within  the  Defense  Acquisition  Management 
System  depicted  in  Figure  10.  The  pre-systems  acquisition  phase  includes  materiel 
solution  analysis  and  technology  development;  however,  the  vast  majority  of  this  effort 
was  centered  on  the  technology  development  phase.  The  equivalent  of  a  materiel 
development  decision  for  this  project  was  essentially  concluded  via  a  previous  decision  to 
explore  the  HE-RPA  concept  as  a  materiel  solution  versus  alternate  doctrine, 
organization,  training,  material,  leadership,  personnel,  or  facilities  (DOTMLPF)  solutions 
[35]. 


•  The  Materiel  Development  Decision  precedes 
entry  into  any  phase  of  the  acquisition 
management  system 

•  Entrance  criteria  met  before  entering  phase 

•  Evolutionary  Acquisition  or  Single  Step  to 
Full  Capability 
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Figure  10:  Defense  Acquisition  Management  System 
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Narrowing  the  scope  to  essentially  the  technology  development  phase  was  a  key 
aspect  of  utilizing  a  tailored  systems  engineering  approach  to  perfonn  the  concept 
evaluation  of  the  HE-RPA  within  a  compressed  development  cycle.  The  inherent 
constraints  of  the  technology  development  phase  limited  the  scope  of  this  effort  to  the 
development  and  demonstration  of  a  prototype  system,  which  was  consistent  with  the 
previously  mentioned  limitations  of  this  effort.  The  HE-RPA  was  considered  an 
emerging  technology  and  had  not  yet  been  successfully  demonstrated  [12]  ,  making  a 
comparative  analysis  to  other  HE-RPA  technology  difficult.  A  key  component  of  the 
concept  evaluation  was  to  determine  the  potential  perfonnance  improvements  resulting 
from  inclusion  of  the  HEPS  over  a  baseline  configuration.  Therefore,  a  component  of  the 
systems  engineering  approach  was  to  include  the  development  and  baseline  evaluation  of 
an  RPA  powered  by  an  ICE  propulsion  system.  All  aspects  of  the  tailored  SE  process 
were  therefore  needed  to  account  for  two  airframes;  airframe  1  (ICE  powered)  and 
airframe  2  (HE  powered). 

Although  tailored  for  the  evaluation  of  the  HE-RPA,  the  selected  approach  still 
encompasses  most  of  the  elements  associated  with  robust  systems  engineering.  These 
elements  were  represented  by  the  systems  engineering  V-model  depicted  below  in  Figure 
11. 
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Figure  1 1:  Systems  Engineering  V-Model  [36] 


The  tailored  SE  approach  leverages  previous  HE-RPA  conceptual  studies  [10,  11, 
20]  to  create  a  CONOPS,  and  the  generation  of  systems  architecture  to  define  system 
requirements  and  to  allocate  system  functions  to  subsystems.  This  approach  also  utilizes 
a  team  concept  somewhat  resembling  an  integrated  product  team.  Team  members 
included  the  authors,  along  with  Ausserer  [12]  and  Giacomo  [13];  contributing  to 
development  of  the  HE  propulsion  system  and  airframe  characterization,  respectively. 

At  project  initiation,  the  HE-RPA  development  team  decided  to  use  the  following 
SE  principles  as  the  foundation  of  the  tailored  SE  process  used  in  this  research. 

•  Event  driven 

•  Defined  entry  and  exit  criteria 

•  Value  added 

•  Formal  and  informal  format 
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The  HE-RPA  development  team  also  identified  the  following  systems  engineering 
activities  as  critical  for  the  development  of  the  HE-RPA  and  essential  to  the  tailored  SE 


process. 

•  Preliminary  design  review 

•  Developmental  test  and  evaluation 

•  DoD  architecture  framework 

•  Human  factor/sy stems  integration 

•  Critical  design  review 

•  Prototype/engineering  development  model 

•  Risk  assessment 

•  System  requirements  review 

•  Systems  engineering  and  technology  development 

•  Test  &  evaluation  master  plan  (TEMP) 

•  Test  Readiness  Review/  Safety  review  Board 

Early  identification  and  solidification  of  primary  research  objectives  and 
evaluation  criteria/questions  lead  to  the  generation  of  measures  of  effectiveness  (MOEs) 
and  measures  of  performance  (MOPs)  for  testing  captured  in  the  TEMP,  Appendix  K. 
Previous  work  conducted  by  Greiser  [24],  Rotramel  [14],  and  Mengistu  [25]  along  with 
concurrent  work  by  Ausserer  [12]  were  utilized  and  tracked  via  an  evolving  integrated 
master  schedule  (IMS)  in  order  to  establish  a  detailed  design  for  the  HEPS.  The  tailored 
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SE  approach  took  advantage  of  previous  work  by  Harmon  et  al  [11,  20]  and  Hiserote 
[20],  as  well  as  ongoing  efforts  by  Giacomo  [13]  for  airframe  design  parameters  for  the 
HE-RPA.  The  component  level  designs  were  evaluated  in  order  to  identify  only  those 
perfonnance  characteristics  and  parameters  that  contributed  to  meeting  the  overarching 
research  objectives  and  evaluation  criteria. 

The  test  planning  and  evaluation  techniques  of  these  objectives  are  addressed 
within  the  TEMP  (Appendix  K)  and  the  evaluation  section  which  follows  later  in  Chapter 
III.  As  this  effort  was  focused  on  the  technology  development  phase  with  a  prototype 
system,  component  and  system  verification  utilized  a  build-up  approach,  incorporating 
three  main  levels  of  testing;  functionality,  safety,  and  performance.  Functionality  testing 
focused  on  basic  system  operation  and  is  intended  to  verify  system  design  and  operation. 
The  HE-RPA  incorporated  potentially  hazardous  systems;  therefore,  it  was  critical  that 
the  safety  aspects  of  the  system  be  vetted  via  the  planned  risk  mitigation  efforts  and 
safety  review  boards.  Ultimately,  the  performance  of  the  HE-RPA  needed  to  be 
characterized  by  the  development  team  in  order  evaluate  the  concept.  Therefore,  ground 
testing  and  flight  testing  were  conducted  in  order  to  collect  sufficient  information. 

Testing  and  evaluation  results  are  discussed  in  detail  in  Chapter  IV. 

As  mentioned  previously,  time  was  the  primary  constraint  to  this  effort. 

Therefore,  risk  analysis  and  risk  management  strategies  were  implemented  throughout, 
with  utmost  attention  on  schedule  risk.  Risk  is  further  addressed  later  in  this  chapter, 
section  3.8. 
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A  key  aspect  of  evaluating  the  hybrid-electric  RPA  concept  using  a  tailored  SE 
process  was  following  an  event  driven  process  focused  on  just  the  elements  deemed 
necessary  to  evaluate  the  prototype  system  against  the  CONOPS.  The  generation  of  an 
initial  IMS  ensured  all  events  were  planned  in  a  logical  and  sequential  manner.  The  IMS 
was  also  critical  to  monitoring  progress  and  managing  risk. 

3.6.  Planned  Schedule 

The  proposed  IMS  for  the  HE -RPA  development  project  is  shown  in  Figure  12 
beginning  with  the  preliminary  design  review  and  ending  with  the  flight  test  of  airframe  2 
which  was  the  HE -RPA.  Figure  12  was  developed  prior  to  the  preliminary  design  review 
and  shows  the  initial  expected  duration  for  each  task.  Although  Microsoft  Project 
presents  the  schedule  as  if  it  were  schedule  driven,  the  schedule  was  actually  event 
driven.  Events  that  were  dependent  upon  the  completion  of  other  events  were  not  started 
until  the  events  that  they  depended  upon  were  completed. 

As  the  HE -RPA  was  being  developed  in  an  academic  environment,  there  were 
some  hard  deadlines  such  as  AFIT  graduation.  The  scope  of  the  HE  development  project 
was  adjusted  as  needed  to  accommodate  these  hard  deadlines.  With  the  proposed, 
schedule  ending  in  September  and  the  graduation  date  set  for  March  22  there  was  some 
room  for  schedule  delays,  such  as  poor  weather,  built  into  the  schedule.  At  inception,  the 
team  understood  that  the  risk  of  poor  weather  delaying  taxi  and  flight  test  increased  for 
each  week  that  the  project  was  delayed. 
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ID 

Task  Name 

0 

1 
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4 
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5 

Microcontroller  development 
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7 

Hybrid  System  II  mount  design 

8 

Hybrid  System  II  mount  fabrication 

9 

Airframe  1  complete 

10 

0  Requirements  review 

11 
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12 

Testing  location  decision 

13 

Airframe  2  complete 

14 

Hybrid  Integration 

15 

Flight  Worthiness  Aproval  Airframe  1 

16 

Flight  Worthiness  Aproval  Airframe  II 

17 

3  Critical  Design  Review 

18 

Control  Design  Airframe  1 

19 

Test  Readiness  review  1 

20 

Flight  Test  Airframe  1 

21 

Control  Design  Airframe  2 

22 

Test  Readiness  review  2 

23 

Flight  test  Airframe  2 

24 

Con  Ops 

25 
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27 
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Figure  12:  Planned  FIE-RPA  Development  IMS 


The  critical  path  was  dominated  by  the  development  and  integration  of  the  HEPS. 
Any  delay  in  the  development  and  integration  of  the  HEPS  would  result  in  a  delay  to  the 
program.  The  current  schedule  shows  a  Hybrid  System  I  and  a  Hybrid  System  II. 
Although  only  two  iterations  of  the  HE  system  were  shown  in  the  schedule,  the 
possibility  of  requiring  additional  iterations  in  the  development  of  the  HE-RPA  was 
considered.  Wherever  possible,  extra  components  were  to  be  ordered  to  allow  for 
component  failure  and  replacement  during  development. 

According  to  the  proposed  schedule,  the  development  of  the  airframes  by  CLMax 
was  not  on  the  critical  path.  Although  the  airframe  development  was  not  on  the  critical 
path,  it  was  a  task  that  was  closely  monitored  by  the  authors  because  it  was  the  task  over 
which  the  HE-RPA  development  team  had  the  least  control.  Some  fabrication  delay  was 
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predicted  as  a  probable  event,  and  a  lengthy  delay  was  predicted  as  a  possibility.  If  the 
delay  were  long  enough,  then  the  airframe  development  would  have  become  part  of  the 
critical  path.  It  was  anticipated  that  lessons  learned  during  the  development  and  flight 
test  of  the  airframes  by  CLMax  would  assist  in  the  integration  and  flight  test  by  the  HE- 
RPA  development  team. 

3.7.  System  Development 
i.  7. 1.  Prior  Efforts 

Research  previously  conducted  by  Hannon  et  al  [10,  11,  20]  and  Hiserote  [20] 
resulted  in  a  conceptual  design  for  a  small  (30  -  50  lb)  hybrid-electric  RPA.  The  HEPS 
design  was  based  on  a  two-point  design,  which  included  an  ICE  sized  for  cruise  speed 
(ingress/egress)  as  well  as  an  electric  motor  and  a  battery  pack  sized  for  a  slower 
endurance  speed  (loiter).  This  parallel  HE  design  gave  the  vehicle  longer  time  on  station 
and  greater  range  than  electric-powered  vehicles,  in  conjunction  with  smaller  acoustic 
and  thermal  signatures  than  those  currently  used  in  gasoline -powered  propulsion  systems. 
A  basic  model  of  the  parallel  HE  system  is  shown  in  Figure  13. 


Figure  13:  Conceptual  Parallel  Hybrid-Electric  System 
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The  prior  research  also  produced  the  segmented  ISR  mission  profile  previously 
depicted  in  Figure  2.  These  efforts  further  resulted  in  the  conceptual  design  for  the 
airframe  component  of  the  FIE-RPA.  With  a  focus  on  the  mission  critical  segment, 
endurance  ISR  collection,  the  resulting  airframe  design  consisted  of  an  airframe  with  a 
high  aspect  ratio  wing,  which  minimized  the  power  consumption  and  thrust  required. 
The  optimization  efforts  conducted  by  Harmon  and  Hiserote  [20]  yielded  specific 
airframe  design  parameters,  some  of  which  are  detailed  in  Figure  14.  These  conceptual 
efforts  lead  to  the  actual  hybrid-electric  propulsion  system  and  airframe  development 
discussed  below. 


Parameter 

Value 

Units 

Wing  Loading,  ID'S 

90.00 

N/m2 

Aspect  Ratio,  AR 

14.42 

- 

Wing  Planform  Area,  5 

1.48 

nr 

Wing  Span,  b 

4.62 

m 

Wing  Chord,  c 

0.321 

m 

Max  Lift  Coefficient,  Ci  ^ 

1.25 

- 

Stall  \elocity,  Vstaii 

11.84 

m/s 

Theoretical  Endurance  \elocity,  tkeor 

9.27 

m/s 

Actual  Endurance  Velocity,  Extort  act 

14.41 

m/s 

Figure  14:  Optimized  Airframe  Design  Parameters 


3. 7.2.  Airframe  Development  &  Procurement 

As  a  prelude  to  the  HE-RPA  conceptual  evaluation,  the  aforementioned  airframe 
design  parameters  were  utilized  to  provide  a  design  specification  to  the  contracted 
airframe  developer,  CLMax.  Prior  to  any  airframe  component  fabrication,  an  informal 
preliminary  design  review  was  held  at  AFIT  to  re-confirm  design  specifications  and 
ensure  the  airframe’s  ability  to  accommodate  the  planned  integration  of  the  hybrid- 
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electric  propulsion  system.  This  meeting  yielded  the  agreement  to  proceed  with  the 
fabrication  of  two  airframes  (one  for  the  previously  mentioned  baseline  analysis  and  the 
other  for  hybrid-electric  integration).  Details  of  bulkhead  and  fuselage  configurations 
were  also  discussed,  ensuring  adequate  room  for  the  hybrid-electric  system,  fuel, 
batteries,  and  avionics.  It  was  also  agreed  that  a  determination  of  the  final  wingspan,  12 
ft  or  15  ft,  could  be  agreed  upon  at  a  later  date.  The  preliminary  allocation  of 
components  is  detailed  below  in  Figure  15. 


Inner  Cross 
Sectional  Dims 
3.75"  w  x  6.625"  h 
w/  Vi"  corner  fillets 
Outer  Cross 
Sectional  Dims 
4.25"  w  x  7.125"  h 
w/  %"  corner  fillets 


Wine  Installed  through  Fuselage  side  (CNC 


Figure  15:  Preliminary  Allocation  of  Airframe  Components 


Findings  by  Giacomo  [13],  indicated  that  the  airframe  design  would  have  lateral 
stability  issues  at  the  optimized  15-ft  (4.62  m  noted  above)  wingspan  configuration.  To 
mitigate  the  potential  risk  associated  with  testing  a  marginally  stable  15-ft  wingspan,  the 
development  team  determined  that  a  12-ft  wingspan,  capable  of  being  re-configured  to 
the  15-ft  wingspan  with  two  18  inch  wingtip  extensions,  was  the  preferred  alternative. 
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The  modular  wing  design  would  also  enhance  transportability  of  the  airframe.  The  12-ft 
configuration  was  also  ideal  as  it  would  allow  for  testing  to  be  conducted  in  a  build-up 
manner  and  mitigate  the  risk  associated  with  taxiing  a  high-aspect  ratio  wing. 
Incremental  updates  and  airframe  fabrication  status  was  also  agreed  upon.  Photographs 
detailing  intermediate  fabrication  steps  are  shown  below  in  Figure  16  and  Figure  17. 


Figure  16:  CLMax  Wing  Loading  Tests  (15-ft  Wingspan) 


Figure  17:  CLMax  Wing  Load  Testing 
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Coinciding  with  the  airframe  fabrication,  an  aircraft  performance  model  was 
developed  in  order  to  generate  the  stability  and  control  parameters  needed  in  order  to 
operate  the  HE-RPA  under  the  planned  autopilot  control.  A  Matlab/Simulink  model  was 
created  by  Giacomo  [13]  in  order  to  determine  the  appropriate  range  of  proportional, 
integral,  and  derivative  (PID)  control  values  that  were  required  by  autopilot  navigation 
and  control  systems.  An  overview  of  the  aircraft’s  longitudinal  control  structure  is  shown 
in  Figure  18.  Verification  of  the  model  and  the  control  values  is  included  as  the  initial 
component  of  the  baseline  airframe  (AFIT  1)  evaluation  and  testing. 


3.8.  Risk  Analysis 

The  proposed  schedule  shown  in  Figure  12  outlines  three  main  objectives: 
develop  and  fly  the  Condor  airframe,  develop  a  suitable  HEPS,  and  finally  integrate  the 
HEPS  into  the  airframe  and  then  fly  the  HE-RPA.  If  either  of  the  first  two  events  were 
not  achieved,  then  the  third  event  could  not  have  been  achieved.  Each  of  the  three  events 
constituted  a  risky  project  in  their  own  right.  Due  to  the  aggressive  scope  of  the  project 
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as  a  whole,  a  robust  risk  management  plan  including  qualitative  and  quantitative  risk 
analysis  was  required. 

3.8.1.  Qualitative  risk  analysis 

A  qualitative  risk  assessment  was  conducted  by  the  HE-RPA  development  team 
during  project  initiation  and  is  included  as  Appendix  H.  The  identified  risks  were  flight 
test  approval,  HE  development/configuration,  risk  of  crashing  an  airplane,  further 
fabrication  shop  delays,  feedback  control,  and  improper  propeller  type.  Under  each  risk 
is  a  description  of  the  risk,  a  planned  mitigation  effort  and  an  expected  impact  if  the  risk 
were  to  occur.  Near  project  completion,  the  qualitative  risks  identified  at  project 
initiation  were  revisited  and  a  results  section  for  each  risk  was  added. 

3.8.2.  Quantitative  risk  analysis 

Due  to  the  high  level  of  uncertainty  in  the  proposed  schedule,  there  was  also  a 
degree  of  uncertainty  regarding  which  tasks  were  on  the  critical  path.  If  tasks  initially  on 
the  critical  path  took  less  time  to  complete  than  expected,  and  events  not  on  the  critical 
path,  such  as  airframe  fabrication,  took  more  time  than  expected,  then  they  could  have 
become  part  of  the  critical  path.  Nicholas  and  Steyn  [37]  recommend  using  a  network 
diagram  to  illustrate  a  schedule  and  its  tasks. 

Activities  A  through  O  in  Table  5  were  selected  as  nodes  for  the  network  diagram 
shown  in  Figure  19.  Each  of  the  HE-RPA  development  team  members  were  asked  for  a 
best  guess  at  the  minimum,  likely,  and  maximum  number  of  weeks  that  it  would  take  to 
accomplish  each  task.  The  average  likely  duration  was  used  to  populate  the  duration  of 
each  task  in  the  network  diagram  shown  in  Figure  19. 


53 


The  following  equations,  outline  by  Nicholas  and  Steyn  [37]  were  used  to 
generate  the  other  fields  in  the  network  diagram. 

Finish  time  =  Start  time  +  Duration  -1 

Early  Finish=  Early  start  +  Duration  -  1 

Late  start  =  Late  finish-  Duration  +  1 

Total  slack  =  Late  start-  Early  start  =  Late  finish  -  Early  finish 

Free  slack  for  activity  =  Early  start  (earliest  successor)  -  Early  finish 
(activity)  -  1 

Nicholas  and  Steyn  [37]  explained  that  the  early  start  and  finish  represent  the  soonest  that 
a  task  can  be  started  or  finished,  while  the  late  start  and  late  finish  represent  the  most  that 
a  task  can  be  delayed  before  it  further  delays  the  critical  path  and  the  project  as  a  whole. 
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Table  5:  Network  Diagram  Activities 


Duration 

Activity 

Description 

min 

likely 

max 

A 

Build  EM  system 

225 

4 

6 

B 

Build  ICE  system 

2.75 

4.125 

7 

C 

Build  Airframes 

17 

23.5 

36.5 

D 

Bench  test  EM  system 

1.5 

2.5 

4 

E 

Bench  test  ICE  system 

1.5 

325 

8 

F 

Build  HE  system 

4.75 

725 

14 

G 

Integrate  A  FIT  1 

1.5 

3 

5 

H 

Bench  test  HE  system 

2.5 

3.5 

5.75 

I 

Taxi  test  A  FIT  1 

0  875 

1  25 

2.25 

J 

Integrate  A  FIT  2 

1.5 

3 

5 

K 

Flight  test  AFIT  1 

225 

3.5 

6.5 

L 

AFRL  flight  test  approval 

2 

4.25 

7 

M 

Bench  test  AFIT  2 

125 

2.75 

4.25 

N 

Taxi  test  AFIT  2 

0.875 

1.5 

2.75 

O 

Flight  Test  AFIT  2 

1.75 

3.5 

6.75 

0  ST  0 

0  A  4 

4  D  6.5 

7.4  F  15 

15  H 

0  0 

0.8  0 

6.8  0.9 

5.9  0 

5.9 

0  0  0 

6.8  4  11 

11  2.5  13 

13  73  21 

21  3.5 

27  L  31 
0.5  0.5 ' 

2^  4.3  31 


IDsActiwtyCode 
DURS  Duration  mw< 
ES  =  Early  Start 
EF= Earty  Finish 
TS  =  Toel  Slade 
FS  =  Free  Slat* 
LS=lafi  Start 
LF=lateF«usii 


29  N  31NJ31  0  35 
0.5  0.5  — t  0  0 


30  li  31x1 31  3.5l  35 


35  END  35 
0  NA 
35  0  35 


Figure  19:  HE-RPA  network  calculations 
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Due  to  the  high  degree  of  uncertainty  in  the  estimation  of  the  minimum,  likely, 
and  max  duration  of  each  task,  a  Monte  Carlo  Simulation  was  used  to  generate  100 
simulated  passes  through  the  network  diagram.  Each  task  was  approximated  by  a 
triangle  distribution.  A  random  sample  of  each  task  was  selected  for  each  pass  through 
the  network  diagram.  The  resulting  durations  of  each  pass  were  sorted  into  bins  and  the 
results  are  shown  in  Figure  20. 
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Figure  20:  Estimated  FIE-RPA  project  duration  in  weeks 


According  to  the  results  of  the  Monte  Carlo  Simulation  shown  in  Figure  20,  the 
FIE-RPA  project  could  have  been  accomplished  in  42  weeks  with  an  80%  confidence 
level.  With  a  start  date  of  January  27,  201 1,  a  42  week  duration  would  have  equated  to  a 
completion  date  of  November  15,  201 1.  The  35  week  duration  that  would  have  resulted 
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if  each  task  took  the  average  likely  duration  equates  to  a  completion  date  of  September 
29,  2011  which  matches  the  schedule  shown  in  Figure  12.  Based  on  the  estimates 
provided  by  the  HE-RPA  development  team  members  and  the  Monte  Carlo  Simulation 
there  was  only  a  20%  chance  that  the  project  would  be  completed  by  September  29, 
2011.  This  estimation  appears  to  have  been  overly  optimistic.  Although  the  schedule 
was  optimistic,  the  critical  path  was  identified  and  priority  was  given  to  tasks  on  the 
critical  path.  The  team  understood  that  the  longer  it  took  to  accomplish  tasks  on  the 
critical  path,  the  higher  the  probability  of  unfavorable  weather  during  taxi  test  and  flight 
test. 

3.9.  System  Integration 

The  planned  integration  efforts  primarily  focused  on  bringing  all  aspects  of  the 
hybrid-electric  propulsion  system,  airframe,  and  ground  control  station  together  in  a 
succinct  manner  to  facilitate  evaluation  and  testing.  Integration  efforts  were  split  into 
two  primary  areas:  incorporating  the  autopilot  hardware  and  flight  control  modeling 
outputs  into  the  baseline  aircraft,  AFIT  1,  and  combining  the  autopilot  hardware,  hybrid- 
electric  propulsion  system  and  motor  controller  into  the  HE-RPA,  the  “as-built” 
configuration,  also  called  AFIT  2. 

3.10.  Evaluation 

In  order  to  satisfy  the  research  objectives  and  to  evaluate  the  HE-RPA  concept  as 
a  viable  option  meeting  the  capability  requirements  set  forth  in  the  CONOPS,  an  orderly 
progression  of  testing  was  conducted.  Governed  by  the  TEMP,  shown  in  Appendix  K, 
testing  efforts  were  allocated  into  three  primary  avenues  as  detailed  in  the  test  and 
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evaluation  hierarchy,  Figure  21.  Planned  concurrently,  development  and  evaluation  of 
the  hybrid-electric  propulsion  system  and  airframes  was  completed  prior  to  integration 
efforts  and  evaluation  of  a  complete  prototype  FIE-RPA  system.  A  specific  test 
methodology  and  test  strategy  for  evaluation  of  the  hybrid-electric  propulsion  system, 
airframe,  and  integrated  HE-RPA  was  created  and  documented  herein. 


Figure  21:  Test  and  Evaluation  Hierarchy 


3.11.  T&E  Strategy 

A  test  and  evaluation  strategy  was  established  in  order  to  facilitate  a  logical  and 
succinct  progression  of  activities  and  is  a  component  of  the  tailored  SE  process  utilized  in 
this  effort.  The  primary  purpose  of  testing  this  system  was  to  collect  information  needed 
to  generate  a  concept  evaluation  for  a  RPA  powered  by  an  HEPS.  However,  the 
cooperative  aspect  of  this  effort  also  necessitated  minor  additions  and  deviations  to  test 
events  in  order  to  satisfy  the  research  objectives  levied  by  Ausserer  and  Giacomo.  These 
additions  and  deviations  were  primarily  related  to  validation  of  the  RPA  flight  simulation 
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model  and  integration  and  validation  of  the  HEPS.  Specific  test  events  and  the 
corresponding  rationale  are  presented  in  Ausserer  [12],  Giacomo  [13],  and  the  bench, 
ground,  and  flight  test  cards  in  0. 

Testing  followed  a  planned  progression  in  order  to  maximize  component 
availability  and  to  minimize  the  impact  of  unanticipated  results  or  findings.  It  also 
facilitated  a  piecemeal  evaluation  of  component  technologies  including  the  standalone 
HEPS,  the  RPA  platform,  the  autopilot  and  ground  control  station,  and  the  motor 
controller  logic/strategies.  A  detailed  description  of  the  planned  test  events  is  captured  in 
the  TEMP,  Appendix  K.  The  T&E  strategy  focused  on  event  driven,  incremental, 
evaluations  in  accordance  with  the  T&E  hierarchy.  System  testing  was  segmented  into 
the  three  following  areas: 

•  Component/Hardware-in-the-Loop  Bench  Testing; 

•  Developmental  Ground  Test; 

•  Developmental  Flight  Test. 

3.12.  Bench/Ground/Flight  Testing 

Coinciding  with  the  tailored  SE  approach,  evaluation  and  testing  followed  an 
event  driven  approach  for  both  AFIT  1  and  AFIT  2.  Test  events  were  in  concordance 
with  system  maturity  and  risk  mitigation  measures.  Initial  bench  testing  was  conducted 
to  verify  functionality  of  individual  components  of  the  system  and  integrated  system 
functionality.  Ground  testing  of  the  RPAs  commenced  after  successful  execution  of  the 
bench  test  cards.  The  test  sequences  and  high  level  test  objectives  are  detailed  below. 
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3.12.1.  Bench  Testing  (Component/hardware-in-the-loop) 


Bench  testing  for  this  system  consisted  of  evaluations  of  individual  hardware 
components  and  subsystems  for  both  the  HEPS  and  the  RPA  airframes,  as  well  as 
partially  and  fully  integrated  hardware  and  software  components.  Testing  was  conducted 
with  prototype  or  representative  items  in  order  to  simulate  operational  conditions  and 
employment  scenarios.  The  primary  purpose  of  the  component/hardware-in-the-loop 
testing  was  to  observe  system  functionality  and  to  collect  and  verify  system  data  outputs. 
The  objectives  and  sub-objectives  shown  in  Table  6  were  incorporated  into  the  test  and 
evaluation  strategy  and  deemed  necessary  to  develop  the  HE-RPA  system  and  provide  an 
objective  concept  evaluation.  A  synopsis  of  the  results  is  presented  in  Chapter  IV  and 
detailed  results  were  documented  by  Giacomo  [13]  and  Ausserer  [12]. 

Table  6:  Planned  Component/Hardware  In-the-Loop  Testing 


Component/Hardware-in  the-Loop  Testing 

Basic  Components 

Integrated  Components 

Electric  Motor  Basic  Function 

Dual  Mode  Testing 

ICE  Engine  Basic  Function 

HE  Motor  Only  Acoustic  Testing 

Camera  ComponentTesting 

HE  Motor  and  Propeller  Acoustic 
Testing 

Motor  Controller 

HE  Motor  Endurance  Testing 

Engine  Restart 

HE  Mode  Testing 

Software  in-the-Loop-Testing 

3.12.2.  Developmental  Ground  Testing 

The  primary  purpose  of  the  developmental  ground  testing  was  to  evaluate  the 
perfonnance  of  AFIT  1  (including  baseline  acoustic  measurements)  and  the  results  of 
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integrating  the  HEPS  into  AFIT  2  along  with  the  associated  ground  control  station 
components  and  evaluation  of  the  control  strategies.  Testing  also  focused  on  data 
collection  only  possible  via  a  complete  and  functional  system.  Results  of  the  testing 
determined  the  readiness  of  the  system  for  flight  testing.  A  breakdown  of  the  test  events 
is  presented  in  Table  7. 


Table  7:  Planned  Developmental  Ground  Testing 


Developmental  Ground  Testing 

System  Integration  Test 

Acoustic  Testing  -  Airframe 

Operator  Familiarization  and  Training 

Camera  Testing 

HE  &  ICE  Control  Surface  Testing 

Radius  on  Ground 

Operational  Checkouts 

Range 

HE  Mode  Control  w/  all  Electrical 
Systems  Operating 

Mounted  on  Stand 

Operation 

Camera  switching 

Software  in-the-Loop  Testing  & 
Emergency  Recovery 

Emergency  Procedures 

Ground  Station  Testing 

System  Recovery 

3.12.3.  Developmental  Flight  Testing 

The  first  flight  tests  were  planned  to  be  conducted  with  a  prototype  aircraft 
developed  by  CLMax.  The  purpose  of  the  prototype  flight  test  was  to  discern  the  initial 
airworthiness  of  the  aircraft.  Prototype  testing  was  to  be  conducted  solely  at  the 
discretion  of  the  contractor  with  results  being  passed  to  AFIT. 

Additional  flight  tests  were  to  be  performed  on  each  of  the  two  airframes 
developed,  a  basic  ICE  only  configuration  and  HE  configuration  with  the  hybrid-electric 
propulsion  system.  One  objective  of  the  project  was  to  show  how  the  HE  aircraft 
compared  to  a  similar  ICE  aircraft  in  regards  to  quiet  operation,  long  loiter  time,  and  fuel 
efficiency.  The  purpose  of  the  ICE  airframe  was  to  provide  a  control  article  for  this 
comparison  and  provide  spare  parts  as  needed  for  the  HE  airframe. 
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The  ICE  airframe  was  to  be  delivered  in  a  flight  ready  configuration  and  the  HE 
aircraft  would  require  HE  motor  integration  prior  to  flight.  The  ICE  aircraft  would 
initially  be  flown  with  a  weight  and  center  of  gravity  (CG)  configuration  matching  the 
HE  aircraft.  Flight  test  data  would  then  be  used  in  final  integration  of  the  HEPS  into  the 
HE  aircraft.  The  HE  aircraft  and  the  ICE  aircraft  in  an  out-of-the-box  configuration  were 
to  be  flown  under  similar  flight  conditions  for  comparative  purposes. 

Finally,  the  HE  aircraft  was  to  undergo  additional  flight  testing  in  order  to 
evaluate  the  enhanced  capabilities  of  the  HEPS.  Specific  test  events,  along  with  the 
appropriate  configuration,  are  presented  in  Table  8. 

Table  8:  Planned  Flight  Test  Objectives 


Flight  Testing 

Both  Aircraft  Configurations 

ICE  Aircraft  Configured  with  HE 
Weight  and  CG 

HE  Aircraft 

Ground  Takeoff 

Maximum  Takeoff  Weight 
Determination 

Fly  with  Different  Numbers  of  Batteries 

Catapult  Takeoff  (if  required) 

HE  Mode  Thrust  Requirement 
Determination 

Aerial  Restart 

Flight  Mode  Test  (taxi,  launch,  climb, 
cruise,  loiter,  recharge,  land) 

Maximum  Endurance 

Proportional-Integral-Derivative  (PID) 
loop  shaping  (longitudinal  and  lateral 
mode  testing) 

In-flight  Mode  Switching 

Camera  Tests 

RemoteAuto  Mode  Switching 

Endurance  Testing 

Operator  Familiarization  and  Training 

Software  in-the-Loop 

Contingency  Testing  (ex.  comm  out) 

Acoustic  Testing  at  Altitude 
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3.13.  Summary 


This  chapter  mirrored  a  SEP  and  established  the  methodology  for  evaluating  the 
proposed  capability  in  the  CONOPS  using  a  tailored  SE  process  with  a  concrete  systems 
architecture,  a  qualitative  and  quantitative  risk  analysis,  and  an  established  TEMP.  The 
next  chapter  outlines  the  results  of  the  system  integration  and  testing  as  well  as  the  results 
of  the  tailored  SE  process. 
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IV  Results 


4.1.  Chapter  Overview 

With  the  development  of  the  systems  architecture,  the  SE  approach,  and  airframe 
fabrication  complete,  the  remaining  effort  shifted  to  system  integration,  testing  and 
validation.  The  first  section  of  the  chapter  focuses  on  evaluation  of  the  baseline  airframe 
configured  with  the  ICE  and  Kestrel  autopilot  [38]  (AFIT  1).  The  chapter  continues  with 
a  discussion  on  the  integration  and  modification  efforts  required  in  order  to  prepare  AFIT 
1  and  progress  to  an  evaluation  of  the  HE-RPA  (AFIT  2).  The  chapter  then  focuses  on  an 
evaluation  of  AFIT  2  and  a  discussion  of  the  overarching  research  objectives  and 
technology  readiness  level,  including  an  evaluation  of  acoustic  perfonnance.  Finally,  a 
discussion  on  the  ability  of  the  HE-RPA  to  fulfill  the  capabilities  specified  in  the 
CONOPS  and  the  impact  of  using  a  tailored  SE  approach  is  presented. 

The  risk  levels  associated  with  progressive  testing  increased  with  the  subsequent 
completion  of  test  events.  Initial  testing  was  done  at  the  modeling  and  simulation  (M&S) 
level,  followed  by  component/breadboard  levels,  then  evolving  into  integrated  system 
ground  testing  (hardware-in-the-loop  testing),  and  finally  culminating  in  flight  testing, 
evaluating  both  AFIT  1  and  AFIT  2. 

Critical  to  overall  system  success,  testing  of  the  HEPS  was  conducted  throughout 
all  phases  of  assembly  and  integration.  Flight  testing  efforts  were  divided  between  two 
vehicles;  AFIT  1,  the  ICE  only  configuration  and  AFIT  2,  the  HE  configuration.  AFIT  1 
was  tested  with  a  weight  and  balance  configuration  mirroring  the  weight  and  balance 
properties  expected  of  AFIT  2.  Lessons  learned  during  the  AFIT  1  flight  test  were 
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utilized  in  the  final  development  and  flight  testing  of  AFIT  2.  Tests  that  pose  little  or  no 
threat  to  the  HEPS  and/or  the  airframes  were  conducted  prior  to  test  points  deemed  to 
pose  a  higher  risk. 

4.2.  HE-RPA  System  Development  and  Integration 

The  baseline  configuration,  AFIT  1,  was  developed  and  flight  tests  yielded  critical 
information  about  RPA  perfonnance  and  insight  into  the  development  of  AFIT  2. 
Additionally,  the  HEPS  was  successfully  integrated  into  AFIT  2.  The  original  design  of 
AFIT  1,  AFIT  2,  and  the  HEPS  were  altered  throughout  the  development  and  fabrication 
process  as  more  insight  into  the  systems  was  acquired. 

4.2.1.  Baseline  RPA  -  AFIT  1 

As  the  HEPS  is  currently  a  one-of-a-kind  prototype  system,  the  baseline  RPA, 
AFIT  1,  was  used  to  validate  the  airworthiness  of  the  airframe  before  integrating  and 
risking  the  hybrid-electric  propulsion  system.  The  airframe  design  was  previously 
optimized  by  Hannon  and  Hiserote  [20,  39].  The  baseline  airframe  consisted  of  a  foam 
and  fiberglass  fuselage  and  foam  and  fiberglass  12-ft  wing  set  with  aluminum  spars.  The 
wing  set  also  included  a  set  of  two  18-inch  wingtip  extensions,  allowing  for  a  15-ft 
wingspan  if  desired.  A  Honda  GX35  (35cc)  4-stroke  gasoline  engine  was  also  included 
with  the  baseline  airframe.  The  GX35  provides  approximately  the  thrust  anticipated  from 
the  HEPS  [25], 

As  the  baseline  airframe  was  delivered  in  a  bare  state  with  a  standard  elevator, 
rudder,  aileron,  and  throttle  configuration,  modifications  were  needed  in  order  to 
integrate  the  components  required  in  order  to  add  a  Kestrel  autopilot  system  and  fly  the 
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aircraft  remotely  or  autonomously.  More  specifically,  the  Kestrel  autopilot  utilized  static 
and  dynamic  pitot  probes  for  airspeed  determination,  a  GPS  receiver  for  navigation,  and  a 
modem  for  communicating  with  the  ground  control  station.  The  static  and  dynamic  pitot 
probes  were  added  to  the  center  wing  section,  connecting  to  the  autopilot  through 
internally  routed  pitot  tubing.  Additionally,  a  u-Blox  GPS  [38]  module/receiver  was 
added  to  the  top  of  the  fuselage.  A  Microhard  900MHz  digital  modem  and  antenna  [38] 
were  installed  into  the  fuselage  in  order  to  communicate  with  the  Procerus  Commbox 
vl.l  [38]  and  laptop  component  of  the  GCS.  These  components  were  easily  integrated 
into  the  airframe  as  there  was  ample  room  and  they  are  commercial  parts  recommended 
by  Procerus,  manufacturer  of  the  Kestrel  autopilot.  Figure  22  provides  a  general  view  of 
the  integrated  components  (outer  wing  panels  not  shown). 


Figure  22:  Integrated  Components 


As  delivered,  the  baseline  airframe  was  configured  with  fall-away  landing  gear  in 
order  to  minimize  in-flight  drag.  However,  this  necessitated  a  belly  landing  for  recovery. 
For  this  effort,  the  impact  of  the  added  drag  from  the  landing  gear  was  deemed  negligible 
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for  the  intended  research  objectives  and  a  trade-off  for  the  reduced  landing  risk  was  made 
by  fixing  the  landing  gear  to  the  bottom  of  the  fuselage.  Additionally,  a  mishap  on  the 
first  flight  attempt  and  a  subsequent  taxiing  off  of  the  runway  identified  an  inherent 
structural  weakness  at  the  wing  attachment  points.  This  finding  lead  to  the  incorporation 
of  1/8  inch  thick  plywood  plates  to  the  sides  and  underside  of  the  fuselage  for  needed 
structural  strength. 

Since  the  airframe  is  a  unique  configuration  and  the  stability  and  control  and 
handling  qualities  were  unknown.  Therefore,  an  aircraft  model  created  by  Giacomo  [13] 
was  used  to  predict  aircraft  behavior  and  the  identification  of  the  required  PID  feedback 
loops  required  by  the  autopilot.  The  gains  associated  with  the  PID  loops  were  loaded  and 
integrated  onto  the  autopilot  via  Procerus’s  Virtual  Cockpit  GCS  software. 

Although  envisioned  as  a  much  smaller  operational  footprint,  the  GCS  utilized  for 
this  development  effort  consists  of  a  contractor  provided  trailer  housing  the  laptop  with 
the  Procerus  Virtual  Cockpit  software  and  Commbox,  antennas,  video  receiver,  video 
monitors,  and  power  sources.  The  integration  of  these  components  was  straightforward 
as  they  used  standard  power,  USB,  coaxial,  and  RCA  connections.  The  Virtual  Cockpit 
GCS  software  is  a  companion  product  to  the  Kestrel  autopilot  enhancing  the 
interoperability  of  system  components.  Figure  23  showing  an  overview  of  the  integrated 
GCS  is  shown  below. 
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Figure  23:  Integrated  GCS  Components 


An  engine-kill  mechanism,  an  independent  method  for  aircraft  position 
identification,  and  engine  pull-start  were  integrated  into  AFIT  1  for  safety  reasons. 
Without  a  verified  set  of  PID  values,  the  first  flight  would  be  inherently  risky.  Therefore, 
a  hobbyist  2.4GHz  receiver  and  transmitter  were  used  to  activate  a  pico  switch  relay. 

The  switch  was  tied  to  the  engine  magneto  line,  thereby  providing  an  independent  engine 
kill  mechanism  should  the  aircraft  become  uncontrollable  or  lose  communication  with  the 
GCS  and  require  that  immediate  safety  measures  be  taken.  Without  the  verified  PID 
values,  the  integrated  failsafe  measures  of  the  autopilot  in  the  event  of  a  loss  of 
communication  scenario  could  not  be  relied  upon.  In  order  to  mitigate  this  risk,  a  camera 
pod  transmitting  to  the  ground  station  at  5.8GHz  was  constructed  and  integrated  into  the 
RPA.  The  camera  pod  provided  an  independent,  self-reliant,  visual  reference  to  the 
operator.  If  the  RPA  were  to  lose  communication  with  the  GCS  and  fly  out  of  visual 
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range  of  the  operator,  the  video  image  would  have  provided  an  added  opportunity  to 
locate  and  recover  the  RPA. 

To  further  improve  safety,  an  engine  pull-start  was  added  to  the  back  of  the 
Honda  GX35.  The  pull-start  was  easily  integrated,  as  is  a  standard  option  for  the  Honda 
GX35.  The  addition  eliminated  the  potential  hazard  associated  with  starting  the  engine 
from  a  position  in  front  of  the  aircraft  and  the  tripping  hazard  from  the  required  battery 
and  starter. 

4.2.2.  Hybrid-Electric  RPA  -AFIT  2 

Coinciding  with  the  previously  generated  “as-built”  configuration  presented  in  the 
architecture,  the  hybrid-electric  RPA  required  significant  integration  effort  to  develop  a 
functional  system.  Primarily,  the  HEPS,  motor  controller,  and  motor  control  software 
constituted  the  bulk  of  integration  tasks.  Additionally,  modifications  resulting  from  the 
evaluation  of  AFIT  1  were  integrated  into  AFIT  2. 

As  previously  discussed,  the  fabrication  and  integration  of  the  HEPS  was  on  the 
critical  path  and  constituted  schedule  risk.  Therefore,  monitoring  of  the  integration 
efforts  was  conducted  on  a  weekly,  even  daily  basis.  Coordination  of  team  member 
efforts  was  a  critical  aspect  of  the  integration  of  the  HEPS  into  AFIT  2.  Although  central 
to  this  effort,  the  integration  of  the  HEPS  is  only  briefly  discussed  here;  detailed 
information  on  the  HE  integration  effort  is  covered  by  Ausserer  [12]. 

The  HEPS  consists  of  the  Honda  GX35  engine  mounted  in  parallel  with  the  AXI 
electric  motor  and  linked  via  a  belt  drive.  Intern  team  members  associated  with  the  HE 
system  designed  and  fabricated  the  brackets,  pulleys,  and  adaptors  necessary  to  assemble 
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and  mount  the  system  into  the  HE-RPA  [12].  Additionally,  avionics  mounting  trays  and 
restraints  were  fabricated  in  order  to  integrate  and  mount  the  Kestrel  autopilot,  avionics 
(motor  controller,  telemetry  unit,  and  modem),  fuel  tank,  and  batteries  into  the  fuselage. 
The  associated  wiring  was  also  strategically  placed  to  reduce  electromagnetic 
interference  (EMI)  between  power,  signal,  and  transmission  lines.  An  illustration  of  the 
HE-RPA  layout  is  shown  below  in  Figure  24. 


Hybrid 

Propulsion 

System 


Wing  root 

Avionics 

Fuel 

Batteries 

Kestrel 

Figure  24:  RPA  Layout 


As  discussed  in  Chapter  III  Section  3.7,  the  original  design  of  the  HEPS  was  to 
include  a  microcontroller  capable  of  self-selecting  the  optimal  flight  mode.  Ideally,  a 
fully  operational  HE-RPA  would  implement  control  in  this  manner.  A  PIC32MX795F 
microcontroller  was  selected  as  the  hybrid  controller.  A  full  discussion  of  the 
microcontroller  implementation  is  presented  by  Ausserer  [12].  To  reduce  complexity  and 
risk,  in-line  with  the  tailored  SE  approach,  the  scope  of  the  microcontroller  capabilities 
was  scaled  down.  The  resultant  design  was  to  implement  a  state  machine  on  the  PIC32 
where  the  user,  through  some  form  of  input,  sets  the  flight  mode  via  the  Kestrel  autopilot. 
However,  through  the  course  of  the  HEPS  bench  testing,  an  unanticipated 
electromagnetic  incompatibility  was  discovered  between  the  PIC32  and  the  Kestrel 
autopilot.  Although  implementing  the  mode  control  via  the  PIC32  was  the  preferred 
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alternative,  it  was  determined  that  an  even  more  simplified  control  strategy  could  be 
implemented  and  HE  control  could  be  ported  over  to  the  Kestrel. 


The  authors,  along  with  Ausserer  [12],  decided  to  utilize  an  unused  gimbal  camera 
capability  on  the  Kestrel.  Originally  intended  to  control  two  pulse  width  modulation 
(PWM)  signals  for  two  gimbal  camera  servo  motors,  the  feature  was  instead  used  to 
control  a  PWM  signal  to  the  ICE  throttle  servo,  with  the  second  PWM  signal  converted  to 
an  analog  signal  for  the  electric  motor  control,  via  a  PWM-to-analog  conversion  board 
provided  by  Blue  Point  Engineering.  The  board  is  pictured  in  Figure  25. 


Figure  25:  Servo  to  Analog  Conversion  Board  by  Blue  Point  Engineering 

Operator  control  was  implemented  through  a  Graphical  User  Interface  (GUI) 
developed  by  the  authors,  and  linked  to  the  Procerus  Virtual  Cockpit  software.  The  GUI 
built  upon  an  existing  example  interface  provided  by  Procerus  in  their  Developers  Kit. 

An  excerpt  from  the  created  C++  code  is  provided  in  0.  The  GUI  allows  the  operator  to 
select  a  desired  mode  of  HE  operation,  which  is  in-turn  converted  into  two  PWM  signals 
whose  values  are  a  function  of  the  instantaneous  throttle  signal  provided  by  a  manual 
operator  or  a  direct  autopilot  command.  A  screenshot  of  the  GUI  is  presented  in  Figure 
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26.  This  change  in  HE  control  is  an  additional  deviation  from  the  “as-intended” 
configuration  to  the  “as-built”  configuration. 


Figure  26:  Virtual  Cockpit  user  interface 


4.3.  AFIT  1  Taxi  Testing 

The  taxi  test  of  AFIT  1  was  more  eventful  than  anticipated.  CLMax  had  been 
unable  to  get  the  Condor  prototype  airborne  prior  to  delivery  of  the  airframes.  Some 
minor  adjustments  to  the  Condor  airframe  were  made  by  CLMax  based  on  lessons 
learned  during  attempts  to  fly  the  prototype.  The  primary  change  was  the  replacement  of 
a  tricycle  landing  gear  configuration  in  favor  of  a  tail-dragger  configuration.  The  tail- 
dragger  configuration  increased  wing  incidence  for  greater  lift  and  increase  propeller-to- 
ground  clearance.  The  tricycle  gear  configuration  is  depicted  in  Figure  27  and  the  tail- 
dragger  configuration  is  depicted  in  Figure  28. 
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Figure  27:  Tricycle  Landing  Gear  Configuration 


Figure  28:  Tail-dragger  Configuration 


The  Condor  prototype  failed  to  attain  flight  during  preliminary  testing  by  CLMax. 
An  exact  cause  of  this  failure  was  not  determined.  In  order  to  keep  the  development 
efforts  moving  forward,  the  development  team  decided  to  accept  the  associated  risk  and 
take  delivery  of  the  first  airframe.  Due  to  the  previous  difficulties  with  the  Condor 
prototype,  the  HE-RPA  development  team  did  not  expect  AFIT  1  to  produce  any 
appreciable  lift  during  the  taxi  test.  Therefore,  the  wing  sections  were  installed  for  the 
test  along  with  a  2-bladed  18  x  12  APC  propeller  to  evaluate  the  ground  behavior  of  the 
fully  configured  RPA.  For  this  test  only,  AFIT  1  was  configured  with  only  manual  radio 
control  components;  integration  of  the  autopilot  was  not  necessary  for  this  test.  AFIT  1 
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taxied  well  during  the  taxi  test  and  accomplished  all  required  test  objectives.  During  the 
initial  portion  of  the  taxi  test,  it  was  observed  that  AFIT  1  had  more  than  adequate  lift  for 
flight  by  briefly  leaving  the  ground.  The  HE-RPA  development  team  was  now  much 
more  confident  in  the  ability  for  AFIT  1  to  fly,  due  to  the  results  of  the  taxi  test. 

4.4.  Airworthiness  of  RPA  Airframe 

Due  to  a  requirement  for  restricted  airspace,  flight  tests  were  conducted  at  Hinsel 
Field  located  within  Camp  Atterbury  Joint  Maneuver  Training  Center,  Indiana.  In  order 
to  verify  the  airworthiness  of  AFIT  1 ,  the  baseline  ICE  powered  airframe,  a  series  of 
flight  tests  were  conducted  utilizing  the  build-up  manner  called  out  in  the  T&E  strategy. 
Detailed  flight  test  cards  are  presented  in  0. 

The  initial  flight  of  AFIT  1  resulted  in  an  uncontrollable  flight  condition  and  a 
crash  landing.  It  was  determined  that  a  miscommunication  between  the  test  director  and 
operator  resulted  in  the  Kestrel  autopilot  being  configured  with  an  overly  aggressive  and 
unanticipated  set  of  initial  PID  gain  values.  There  was  no  fault  found  with  the  airframe. 
The  RPA  was  recovered  and  repaired.  A  new  pre-flight  briefing  process  between  team 
members  was  implemented  to  ensure  that  all  members  were  aware  of  the  test  objectives 
and  desired  RPA  configuration,  including  autopilot  parameters. 

Subsequent  flights  were  accomplished  without  incident  according  to  the  flight  test 
cards  and  direction  provided  by  Giacomo  [13].  A  detailed  breakdown  of  specific  flight 
test  objectives  and  results  is  presented  by  Giacomo  [13].  The  RPA  airframe  proved  to  be 
exceptionally  stable  with  very  predictable  behavior  under  manual  control.  Takeoff 
distances,  cruise  speed,  and  stall  speed  were  representative  of  the  values  predicted  by 
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Giacomo  [13],  Harmon  et  al  [20,  1 1],  and  Hiserote  et  al  [39,  20].  The  RPA  also 
demonstrated  acceptable  stability  and  handling  qualities  at  a  configuration  weight  and 
center  of  gravity,  (CG)  simulating  the  expected  values  of  the  HE,  AFIT  2,  configuration. 
Initial  results  were  used  to  validate  the  aircraft  model  created  by  Giacomo.  The  Kestrel 
autopilot  was  configured  and  flown  with  the  model  predicted  PID  values.  Performance 
with  these  PID  values  was  improved  and  once  again  acceptable,  validating  Giacomo’s 
aircraft  model.  The  RPA  airframe  fabricated  by  CLMax  was  deemed  airworthy  and 
suitable  for  integration  of  the  HEPS. 

4.4.1.  AFIT  1  Loiter  Results 

A  specific  objective  of  the  first  flight  test  focused  on  evaluating  the  loiter 
characteristics  of  the  RPA.  AFIT  1  demonstrated  the  ability  to  continually  operate  with 
an  engine  run  time  of  77  min  1 1  sec.  The  flight  test  included  suboptimal  maneuvers 
including  turning  and  changing  elevation.  AFIT  1  took  off  with  approximately  30  fluid 
ounces  of  fuel  and  5  pounds  of  ballast,  weighing  301bs  1 1  oz.  AFIT  1  used  21.5  fl  oz  of 
fuel  on  this  flight.  In  a  subsequent  flight,  AFIT  1  also  demonstrated  that  it  was  capable 
of  flying  with  a  half  tank  of  fuel  and  a  10  lb  ballast  totaling  35+  lbs,  the  anticipated 
weight  of  AFIT  2.  A  test  examining  the  loiter  performance  with  the  optimized  15-ft 
wingspan  was  called  off  after  an  initial  flight  caused  concern  about  the  structural  capacity 
of  the  15-ft  wing  under  gusty  wind  conditions.  No  further  testing  was  conducted  on  the 
15-ft  configuration. 
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4.4.2.  Projected  AFIT 1  Loiter  capability 


The  data  from  the  AFIT  1  loiter  tests  can  be  extrapolated  to  project  a  total  flight 
time  capability.  The  87  octane  gasoline  utilized  for  testing  weighs  0.6133oz/fl  oz.  There 
is  room  in  AFIT  1  to  include  a  second  60  fl  oz  tank  of  fuel  and  additional  avionics 
batteries  to  support  a  long  duration  flight.  Assuming  a  gross  maximum  takeoff  weight  of 
35  lbs,  AFIT  1  can  remove  the  10  lbs  of  ballast  and  replace  it  with  fuel  and  extra 
batteries.  Ninety  additional  fl  oz  of  fuel  would  weigh  3.5  lbs,  leaving  6.5  lbs  for  batteries 
and  other  payload. 

oz 

90  fl  oz  x  0.6133  — —  =  55.197  oz  =  3.5  lbs 
fl  oz 

With  120  fl  oz  of  fuel  and  a  burn  rate  of  77  min  1 1  sec  of  flight  per  2 1 .5  fl  oz  of  fuel, 
AFIT  1  could  conservatively  fly  for  7  hrs  10  min.  Testing  was  not  conducted  with  a 
flight  profile  optimized  for  endurance.  Rather,  it  included  flight  maneuvers  that  consisted 
of  abrupt  changes  in  airspeed,  altitude,  and  heading  and  therefore,  the  estimation  was 
considered  conservative. 

120  fl  oz 

— — — —  x  4631  sec  =  25847  sec  =  7  hrs  10  min  11  sec 

21.5  fl  oz 

4.5.  HE-RPA  Performance 

Central  to  satisfying  the  previously  stated  research  objectives,  verifying  the 
functionality  and  perfonnance  of  the  HE-RPA  was  a  key  aspect  of  the  SE  approach  early 
on  in  this  effort.  Utilizing  the  build-up  approach  specified  in  the  T&E  strategy, 
evaluations  of  the  HE-RPA  were  planned  in  an  event  driven,  incremental  fashion  prior  to 
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initial  integration  of  the  HEPS  into  the  RPA  airframe.  The  build-up  approach  in  the  T&E 
strategy  called  for  bench  testing,  followed  by  ground  and  then  flight  testing  of  the 
integrated  HEPS  after  successful  integration  into  the  RPA  airframe,  AFIT  2 
configuration.  Test  events  are  covered  in  detail  by  Ausserer  [12];  therefore  only  brief 
summaries  of  the  test  events  and  their  impact  on  satisfying  the  research  objectives  are 
presented  here. 

4.5.1.  Bench  Test 

The  primary  objective  of  the  bench  test  was  to  validate  functionality  of  the  HE 
system  and  the  control  and  safety  procedures  intended  for  flight  testing.  A  build-up 
approach  for  the  testing  was  utilized  and  step-by-step  procedures  were  captured  and 
results  documented  in  a  set  of  test  cards  included  as  0.  Basic  functionality  of  the  HE- 
RPA  was  successfully  demonstrated  in  all  modes  of  operation  to  include:  Idle,  ICE  only, 
EM  only,  both  Dual  (Boost)  modes,  and  Regeneration.  A  summary  of  the  results  is 
presented  below  in  Table  9. 


Table  9:  Hybrid  system  bench  test  objectives  and  results 


Test# 

Objective 

Result 

BT-01 

Verify  functionality  of  system  in  ICE  only  mode. 

Successful 

BT-02 

Verify  Functionality  of  system  in  EM  only  mode 

Successful 

BT-03 

Verify  mode  transition  from  EM  only  to  ICE  only  mode  works. 

Successful 

BT-04 

Verify  mode  transition  from  ICE  only  to  EM  only  mode  works 

Successful 

BT-05, 

BT-06 

Verify  both  dual  modes  function.  BT-05  verifies  the  ICE  can  operate  at  a 
constant  set  point  while  the  EM  throttle  is  varied.  BT -06  verifies  the  EM  can 
operate  at  a  constant  set  point  while  the  ICE  throttle  is  varied.  Both  tests  also 
check  that  the  set  point  of  the  constant  component  may  be  changed. 

Successful 

BT-07 

Verify  the  ICE  kill  switch  functions  and  that  the  EM  still  operates  after  the  ICE  is 

Successful 

77 


killed. 

BT-08 

Verify  the  EM  kill  switch  functions  and  that  the  ICE  still  operates  after  the  ICE  is 
killed. 

Successful 

BT-09 

Verify  the  ICE  crossover  switch  to  pass  ICE  control  from  the  Gimbaled  Camera 
line  to  the  Kestrel  throttle  line  during  an  emergency  functions  properly. 

Successful 

BT-10 

Verify  that  Regen  mode  works  properly. 

Successful 

Bench  testing  of  the  HE-RPA  demonstrated  the  HE  technology  could  be 
successfully  implemented  and  integrated  into  an  RPA  and  is  a  viable  option  for  an  RPA 
propulsion  system.  The  bench  testing  also  demonstrated  that  a  control  strategy  for  the 
HEPS  could  be  implemented  for  an  RPA.  Although,  the  envisioned  self-controlled 
capability  via  the  PIC32  microcontroller  was  not  achieved,  implementation  via  the 
Kestrel  autopilot  and  the  Virtual  Cockpit  GUI  demonstrated  that  the  HE-RPA  could  be 
remotely  controlled;  albeit  in  limited  fashion.  The  HE-RPA  bench  test  setup  is  shown  in 
Figure  29. 


Figure  29:  HE-RPA  Bench  Test  Setup 
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4.5.2.  Ground  Test 


The  HE-RPA  team  ensured  that  the  HE-RPA  worked  in  all  of  the  required  modes 
on  the  bench  prior  to  attempting  the  taxi  test.  In  spite  of  the  successful  demonstration  of 
all  the  operational  modes  of  AFIT  2  on  the  bench,  there  were  issues  with  some  of  the 
modes  of  operation  during  the  first  AFIT  2  ground  test.  On  the  flightline,  there  were 
several  issues  trying  to  get  both  the  gas  and  electric  modes  to  function  properly  before 
accomplishing  the  test  objectives  on  the  ground  test  cards  detailed  in  0.  There  was  an 
issue  with  switching  between  modes  and  being  able  to  get  one  mode  or  the  other  to  work 
but  not  both.  This  was  successfully  tested  on  the  bench  just  prior  to  the  ground  test. 

AFIT  2  was  returned  to  AFIT  and  the  HE-RPA  development  team  was 
unable  to  duplicate  the  issue  in  the  lab  so  AFIT  2  was  returned  to  the  flightline  for 
another  taxi  test.  This  time,  the  gas  and  electric  modes  worked,  but  the  Seagull  telemetry 
system  was  not  transmitting  the  telemetry  data  to  the  ground  control  station.  Some 
chatter  in  the  servos,  which  appeared  to  get  worse  as  time  passed,  was  also  observed. 

The  team  was  unable  to  duplicate  the  erratic  behavior  in  a  lab  environment,  so  it  was 
concluded  that  the  servo  chatter  may  have  been  due  to  interference  in  the  900  MHZ 
range,  the  communication  frequency  of  the  autopilot  to  the  GCS.  The  test  location  was 
also  within  range  of  numerous  electromagnetic  testing  facilities  located  at  Wright- 
Patterson  Air  Force  Base.  The  servo  chatter  was  making  the  rudder,  ailerons,  and  even 
the  ICE  throttle  position  servos  quickly  move  to  a  maximum  position  and  then  move  back 
to  the  neutral  position.  Sporadically,  several  servos  would  move  at  once,  and  sometimes 
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just  one  servo  would  move.  The  servo  chatter  happened  about  once  every  10-20  seconds, 
further  indicating  external  EMI. 

Although  not  all  of  the  systems  were  working  as  intended,  the  HE-RPA 
development  team  decided  to  taxi  the  aircraft  in  the  different  modes  and  demonstrate  the 
AFIT  2  capabilities,  even  though  the  telemetry  data  would  not  be  transmitted  or  recorded 
according  to  the  ground  test  cards.  AFIT  2  successfully  taxied  under  EM  only  power  in 
the  first  and  second  HE  taxi  test  events  and  taxied  in  both  dual  (boost)  power  modes  and 
the  ICE  only  mode  during  the  second  HE  taxi  test.  Issues  observed  while  taxing  AFIT  2 
in  ICE  only  mode  were  deemed  insignificant  because  the  chatter  in  the  ICE  throttle  servo 
kept  shutting  off  the  ICE  engine.  AFIT  2  was  taxied  back  to  the  staging  area  after  the 
ICE  engine  was  shut  off  using  the  EM  power,  showing  the  potential  of  redundant  systems 
in  the  HE-RPA.  Although  the  ground  test  was  not  entirely  successfully,  the  HE-RPA 
team  concluded  that  AFIT  2  was  ready  to  progress  to  flight  test  due  to  the  demonstrated 
reliability  of  the  system  in  the  lab  and  confidence  that  the  erratic  behavior  was  due  to 
EMI.  The  team  also  ensured  that  the  issues  observed  during  taxi  test  were  verified  on  the 
flight  line  at  Camp  Atterbury  prior  to  flight  test. 

4.5.3.  AFIT  2  Flight  Test 

No  successful  flights  were  completed  with  AFIT  2  and  no  flight  test  data  was 
gathered  due  to  a  mechanical  failure  in  the  landing  gear,  which  resulted  in  an  unexpected 
departure  from  the  runway.  The  runway  departure  caused  significant  damage  precluding 
continued  testing.  Ausserer  suggested  that  AFIT  2  could  fly  a  loiter  profile  for  an  hour 
and  a  half  without  going  into  regeneration  mode  to  charge  the  batteries.  It  is  difficult  to 
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project  a  realistic  loiter  capability  for  AFIT  2  including  segmented  ISR  via  battery 
regeneration  without  supporting  flight  test  data.  Based  on  the  fuel  consumption  data 
collected  from  AFIT  1,  it  is  reasonable  to  assert  that  the  HE-RPA  concept  has  the 
potential  to  fly  more  than  4  hours  and  fulfill  the  capability  gap  identified  in  Chapter  I;  the 
capability  gap  between  EM  powered  RPAs  and  ICE  powered  RPAs.  Exactly  how  long 
the  HE-RPA  could  fly  including  segmented  ISR  with  battery  regeneration  has  yet  to  be 
demonstrated. 

4.6.  Technology  Readiness 

Based  on  the  results  from  bench,  taxi,  and  flight  test,  the  technology  readiness 
level  (TRL)  of  the  HE-RPA  is  level  5.  The  HE-RPA  capability  has  been  demonstrated  in 
the  lab  via  bench  testing  as  well  as  modeling  and  simulation  but  has  not  been 
demonstrated  in  a  relevant  environment.  Even  if  the  HE-RPA  had  flown  during  flight 
test,  it  would  still  require  a  flight  test  where  a  technician  flew  the  RPA  and  not  the 
engineer  who  designed  it.  Further  human  system  integration  efforts,  upgraded  HE 
targeting  and  control  system,  and  flight  test  demonstrations  are  required  prior  to  a  solid 
TRL  level  6  assessment. 

4.7.  Acoustics 

A  primary  component  of  this  effort  was  to  determine  if  the  addition  of  the  HEPS 
results  in  a  reduction  in  the  acoustic  signature  of  the  RPA.  The  T&E  strategy  called  for 
evaluations  of  both  the  ICE  and  HE  configurations  in  order  to  make  the  comparison. 
Although  AFIT  2  was  not  flow  successfully,  baseline  testing  was  conducted  with  AFIT  1 
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and  qualitative  evaluations  of  AFIT  2  were  made  based  on  findings  with  an  EM  and 
multiple  propellers. 

4. 7.1.  Measurements  and  Results 

Acoustic  measurements  of  AFIT  1  were  collected  at  Camp  Atturbury  concurrently 
with  flight  test  efforts.  Initial  measurements  of  AFIT  1  were  taken  on  the  ground  in  its 
tail-dragger  configuration  with  a  40%  throttle  setting  on  the  ICE  using  the  Ivie  IE -45 
audio  analysis  system  [40],  also  referred  to  as  a  sound  pressure  level  meter.  The  A- 
weighted  measurement  scale  was  chosen  to  remain  consistent  with  comparable  efforts 
[41].  The  40%  throttle  setting  corresponds  to  an  observed  cruise  condition  obtained  via 
initial  flight  testing  of  AFIT  1,  by  Giacomo  [13].  Measurements  were  recorded  in  units 
of  dB(A);  hereto  referred  to  as  simply  dB  (decibels).  The  objective  of  this  first  test  was 
to  evaluate  different  propeller  combinations.  Measurements  were  taken  at  a  50-ft  radius 
with  the  orientation  depicted  in  Figure  30.  No  measurements  were  taken  at  the  315° 
position  (off  the  nose  of  the  aircraft)  due  to  significant  disruptions  caused  by  the  location 
of  the  flight  test  trailer. 
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Figure  30:  Acoustic  Measurement  Location 

Measurements  were  taken  on  four  different  propellers:  a  2-bladed  18x10  APC 
propeller,  a  3-bladed  15.75  x  13  APC  propeller,  a  3-bladed  16x11  Carbon  Fiber  Mejzlik 
propeller,  and  a  4-bladed  15.5  x  10  APC  propeller.  Images  of  each  propeller  are  shown 
in  Figures  31-34. 

Although  these  propellers  do  not  provide  equivalent  performance  (i.e.  thrust)  for 
the  same  rotational  speed,  they  were  deemed  common  and  acceptable  substitutes  without 
resorting  to  custom  designs.  They  were  also  chosen  to  facilitate  the  rapid  prototype  SE 
approach  used  throughout  this  effort. 
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Figure  32:  3-Blade  APC  Propeller  Fi§ure  34:  4-Blade  APC  Propeller 


Recorded  measurements  for  the  2-bladed  18x10  APC  propeller  are  presented  in 
Figure  35.  The  2-bladed  18x10  APC  propeller  was  selected  based  on  previous  findings 
by  Rotramel  [14]  and  serves  as  the  baseline  for  comparison.  Intuitively,  the  lowest  dB 
values  were  obtained  off  of  the  nose  of  the  RPA  at  position  4,  while  the  highest  values 
were  obtained  at  position  5.  Position  5  corresponds  to  the  orientation  of  the  exhaust  port 
on  the  muffler. 
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Figure  35:  dB  Measurements  2-Blade  APC18  x  10  at  50 -ft 


Next,  the  3-bladed  15.75  x  13  APC  propeller  was  tested  and  results  are  presented 
in  Figure  36.  This  blade  exhibited  similar  behavior  trends  in  regards  to  the  minimum 
values  obtained  at  position  4  and  higher  values  obtained  at  position  5.  The  highest  dB 
values  were  recorded  at  position  3.  The  average  dB  value  was  noticeably  higher  for  this 
propeller  than  the  18x10  APC.  Although  not  intended  to  be  an  investigation  on  detailed 
performance  of  propellers,  it  was  surmised  that  higher  values  at  position  3  result  from  an 
interaction  between  the  clockwise  propeller  direction  and  an  air  compression  effect  with 
the  ground.  This  is  consistent  with  findings  in  [41]. 
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Results  for  the  Mejzlik  3-bladed  16x11  carbon  fiber  propeller  are  shown  in 
Figure  37.  This  propeller  had  significantly  lower  dB  values  at  every  measuring  location 
along  with  the  expected  increase  near  the  muffler  port.  This  propeller  was  significantly 
more  rigid  than  the  others  with  a  smoother  surface  finish.  No  conclusions  were  made 
about  the  observed  performance  of  this  propeller. 
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Results  for  the  4-bladed  15.5  x  12  APC  propeller  are  shown  in  Figure  38.  This 
propeller  also  had  significantly  lower  dB  values  than  the  baseline  at  every  measuring 
location  without  the  expected  increase  near  the  muffler  port.  This  propeller  also  had  its 
highest  dB  values  recorded  in  front  of  the  aircraft.  Although  not  captured  quantitatively, 
the  qualitative  observation  put  this  propeller  in  a  different  audible  frequency  range  than 
the  other  three.  This  propeller  was  significantly  more  flexible  and  shorter  than  the  others. 
A  summary  of  the  average  dB  measurements  collected  for  each  propeller  is  shown  in 
Figure  39. 
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Average  Prop  Noise  Levels 


2  3  4  5  6  7 

dB  Measurement  Location 


2- Blade  APC  18x10 

•  3-Blade  APC  15.75x13 

3- Blade  CF  16  x  11 

4- Blade  APC  15.5  x  12 


Figure  39:  Average  Propeller  dB  at  50-ft 


After  collecting  acoustic  measurements  on  the  ground,  AFIT  1  was  flown  at  40% 
throttle  in  an  oval  flight  path  at  altitudes  of  300-ft,  500-ft,  700-ft,  and  900-ft.  Although 
overhead  data  was  collected,  excessive  ground  level  wind  noise  invalidated  the  results. 
Of  note,  team  members  concluded  that  at  the  700-ft  and  900-ft  altitudes,  AFIT  1  was 
barely  discernible  to  the  human  ear  given  ground  wind  speeds  of  3-7  mph  for  all 
propeller  configurations.  This  finding  is  similar  to  one  made  during  testing  of  the  Silver 
Fox  [30].  Z 

Although  the  in-flight  acoustic  measurements  were  invalidated  by  the  wind,  the 
manual  pilot  of  AFIT  1  rank  ordered  the  props  on  responsiveness  to  throttle  command 
(Table  10).  The  2-bladed  18x10  propeller  provided  the  best  performance,  followed  by 
the  Mejzlik  3-bladed  16x11  carbon  fiber  propeller.  The  3-bladed  15.75  x  13  APC 
propeller  was  third  and  the  4-bladed  15.5x12  APC  propeller  performed  the  worst. 
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Table  10:  Responsiveness  Performance 


Responsiveness  Performance 

Rank 

Type 

1 

2-Blade  18x10  APC 

2 

3-Blade  16x11  Mejzlik  CF 

3 

3-Blade  15.75x13  APC 

4 

4-Blade  15.5x12  APC 

Electric  motor  only  measurements  were  collected  on  a  test  stand  at  AFIT.  Testing 
was  limited  to  a  head-on  position  (position  4)  and  limited  to  only  the  3-bladed  15.75  x  13 
APC  propeller,  a  3-bladed  16x11  Carbon  Fiber  Mejzlik  propeller,  and  a  4-bladed  15.5  x 
12  APC  propeller.  Testing  was  not  conducted  on  the  2-bladed  18x10  propeller  due  to 
unavailability  at  the  time  of  the  test.  Both  noise  (dB  level)  and  frequency  response  (Hz) 
findings  are  presented  in  Table  1  land  Table  12. 


Table  1 1 :  Electric  Motor  Acoustic  Noise  Testing  Results 


RPM 


—♦—3-15.75x13 

-»-3-16xllF 

-*-4-15.5x12 
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Table  12:Electric  Motor  Acoustic  Frequency  Testing  Results 


Frequency  Response  -  EM  &  Propellers 


'3-15.75x13' 

•3-16xllF 

4-15.5x12 


4.8.  Evaluation  of  Tailored  Systems  Engineering  Process 

The  event  driven  schedule  with  meaningful  systems  engineering  related  artifacts 
assisted  in  focusing  the  rapid  development  of  the  HE-RPA.  Particular  attention  was  paid 
to  accomplishing  tasks  on  the  critical  path  as  expeditiously  as  possible.  Tasks  that  were 
not  on  the  critical  path  were  monitored  to  assure  that  they  did  not  become  a  part  of  the 
critical  path. 

4.8.1.  Schedule 

Although  the  Monte  Carlo  simulation  predicted  that  the  project  would  take  about 
42  weeks  to  accomplish  with  an  80%  confidence  level,  it  actually  took  56.6  weeks  to 
develop  the  HE-RPA.  Figure  40  shows  the  planned  development  schedule  and  is 
repeated  from  Chapter  III,  shown  again  for  ease  of  reference.  Figure  41  shows  the  actual 
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development  schedule.  By  comparing  both  versions  of  the  schedule,  the  reader  can 
compare  the  planned  versus  actual  completion  time  for  each  scheduled  task. 


The  development  of  airframe  I  and  airframe  II  was  done  in  parallel  since  the  two 
base  airframes  were  very  similar;  airframe  II  did  not  include  a  propulsion  system  since 
the  propulsion  system  was  to  be  developed  by  the  HE-RPA  team.  The  development  of 
the  airframes  was  not  on  the  critical  path,  so  even  though  delivery  was  delayed  by  5 
months  it  did  not  delay  the  project  as  a  whole. 
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Figure  40:  Planned  HE-RPA  Development  Schedule 
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Although  the  longest  task  delay  in  the  project  was  the  airframe  development,  the 
HEPS  development  in  aggregate  constituted  a  much  longer  delay.  It  took  much  longer  to 
build  and  test  the  HEPS  than  anticipated.  There  were  also  significant  delays  regarding 
the  microcontroller  development.  Three  different  microcontrollers  were  used  during  the 
development  of  the  system.  In  the  end,  a  function  built  into  the  Kestrel  Autopilot  that 
was  not  being  utilized  was  modified  to  serve  as  the  microcontroller  for  the  system.  The 
HEPS  development,  including  its  many  setbacks,  is  discussed  at  length  by  Ausserer  [12]. 
The  result  of  the  setbacks  was  that  much  was  learned  about  how  not  to  build  an  HEPS, 
and  much  was  learned  about  how  to  build  a  simpler,  more  robust  HEPS  than  originally 
envisioned. 
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Figure  41:  Actual  HE  PRA  Development  Schedule 
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Another  task  with  a  significant  delay  was  the  integration  of  the  HEPS  into 
airframe  II  to  form  AFIT  2.  Part  of  this  delay  happened  because  the  available  space  for 
avionics  in  the  avionics  bay  changed  several  times.  Ausserer  [12]  provided  the  required 
dimensions  of  the  avionics  bay  to  CLMax  but  did  not  know  that  CLMax  would  put  a 
hinge  and  other  hardware  in  the  avionics  bay.  This  resulted  in  a  redesign  of  the  avionics 
mounting  surfaces.  Later,  while  placing  the  components  in  the  avionics  bay,  Ausserer 
[12]  found  that  other  hardware  was  also  added  to  the  avionics  bay  resulting  in  yet  another 
design  of  the  avionics  mounting  surfaces.  The  team  also  decided  to  add  two  bench  tests 
and  a  taxi  test  to  the  integration  portion  of  the  schedule.  The  first  bench  test  included  the 
HEPS  and  the  avionics  as  well  as  the  propeller.  The  second  bench  test  of  the  integrated 
system  included  the  antennas  and  all  other  components  required  for  flight  test  besides 
wings.  The  additional  testing  took  more  time  than  initially  planned,  but  identified 
unanticipated  deficiencies  in  the  “as-built”  system  configuration  that  had  to  be  corrected 
before  flight  test,  such  as  a  bolt  that  needed  to  be  reverse  threaded  to  prevent  the 
propeller  from  flying  off  the  aircraft  during  operation.  There  was  no  time  planned  or 
allocated  for  troubleshooting  EMI  issues  even  though  it  became  a  major  source  of  delay 
late  in  the  effort. 

Although  the  project  was  designed  to  be  event  driven,  the  end  of  the  project 
coincided  with  the  graduation  date  of  March  22,  2012.  The  HE-RPA  development  team 
knew  that  the  project  was  aggressive  for  the  given  schedule  and  agreed  that  the  team 
would  take  the  project  as  far  as  possible  in  the  time  given.  The  fixed  graduation  date 
assisted  in  scoping  the  concept  during  development  to  increase  the  probability  of 
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accomplishing  the  majority  of  the  objectives,  outlined  in  the  CONOPS,  at  project 
completion. 

4.9.  Qualitative  Risk  Analysis  Highlights 

A  lesson  learned  from  the  results  of  the  qualitative  risk  analysis  was  that  efforts 
taken  to  mitigate  one  risk  may  also  assist  in  mitigating  another  risk.  The  team  requested 
that  the  fuselage  of  the  HE-RPA  be  sent  earlier  in  order  to  expedite  the  integration  of  the 
HE  system  in  the  fuselage.  The  fuselage  that  was  shipped  ended  up  being  a  spare 
fuselage  that  was  used  to  repair  the  aircraft  after  several  rough  landings.  Although  the 
spare  fuselage  was  ordered  to  mitigate  the  integration  risk,  it  actually  mitigated  the  risk  of 
rough  landings  and  did  not  result  in  a  mitigation  of  the  integration  schedule  risk. 

When  discussing  the  progress  of  airframe  fabrication  with  CMax,  CLMax 
explained  that  after  several  flight  test  attempts,  the  fabrication  prototype  aircraft  did  not 
fly.  CLMax  requested  more  time  to  develop  the  airframe  so  that  a  two  cycle  engine 
could  be  ordered  and  replaced  in  the  prototype  airframe  for  further  flight  test  events.  The 
HE-RPA  development  team  detennined  that  the  proposed  schedule  delay  resulting  from 
an  integration  of  a  two  cycle  engine  was  not  worth  the  potential  to  gather  more 
information  about  the  prototype  airframe. 

The  development  team  knew  that  the  airfoil  being  used  was  a  proven  airfoil  and 
was  stumped  as  to  why  the  prototype  airframe  did  not  fly.  The  team  requested  that 
CLMax  deliver  the  airframes  as  planned  even  though  the  flight  potential  was  unproven. 
The  team  decided  to  accept  the  technical  risk  of  having  an  unproven  airframe  in  exchange 
for  the  shorter  delivery  schedule.  The  team  felt  that  the  group  of  aeronautical  engineers 
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involved  in  the  project  with  the  assistance  of  aeronautical  engineering  professors  and 
CESI  support  contractors  would  be  able  to  get  the  airframe  to  fly.  The  team  knowingly 
agreed  to  pay  CLMax  for  two  airframes  that  may  never  fly  and  understood  that  the 
majority  of  test  objectives  would  not  be  accomplished  if  the  airframes  were  not  capable 
of  flying.  A  more  thorough  discussion  of  the  qualitative  risk  analysis  results  is  included 
inO. 

4.10.  Quantitative  Risk  Analysis  Results 

As  discussed  before,  the  primary  risk  to  the  project  was  schedule  risk.  Due  to  the 
generous  funding  from  the  project  sponsors,  the  HE-RPA  development  team  was  able  to 
acquire  parts  and  labor  required  for  development  in  order  to  reduce  the  total  potential 
development  time  of  the  system.  Further,  spare  parts  were  ordered  where  appropriate  to 
avoid  further  delays  should  they  become  necessary. 

As  discussed  in  Chapter  III,  a  survey  of  the  HE-RPA  development  team  members 
was  taken  to  determine  the  expected  duration  of  each  task  in  the  network  diagram.  The 
average  of  the  responses  for  minimum,  likely,  and  maximum  duration  in  weeks  are 
repeated  below  in  Table  13  with  the  actual  task  completion  time  included  as  well. 
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Table  13:  Network  Diagram  Activities  with  Results 


Duration 

Activity 

Description 

min 

likely 

max 

actual 

A 

Build  EM  system 

225 

4 

6 

21.7 

B 

Build  ICE  system 

2.75 

4.125 

7 

21.7 

C 

Build  Airframes 

17 

23.5 

36.5 

28.55 

D 

Bench  test  EM  system 

1.5 

2.5 

4 

4.15 

E 

Bench  test  ICE  system 

1.5 

3.25 

8 

4.15 

F 

Build  HE  system 

4.75 

7.25 

14 

1.3 

G 

Integrate  AFIT  1 

1.5 

3 

5 

1.3 

H 

Bench  test  HE  system 

2.5 

3.5 

5.75 

12.15 

I 

Taxi  test  AFIT  1 

0  875 

1.25 

2.25 

0.15 

J 

Integrate  ART  2 

1.5 

3 

5 

13.3 

K 

Flight  test  AFIT  1 

225 

3.5 

6.5 

12.15 

L 

AFRL  flight  test  approval 

2 

4.25 

7 

0.15 

M 

Bench  test  AFIT  2 

125 

2.75 

4.25 

2.15 

N 

Taxi  test  AFIT  2 

0.875 

1.5 

275 

1 

0 

Flight  Test  AFIT  2 

1.75 

3.5 

6.75 

0.85 

Many  of  the  tasks  took  a  lot  longer  to  complete  than  expected,  showing  that  the 
HE-RPA  development  team  was  either  incredible  unlucky  or  did  not  adequately 
appreciate  the  level  of  schedule  risk  in  the  project. 

Tasks  F,  G,  I,  and  L  took  less  time  than  the  minimum  expected  amount  of  time  to 
complete.  Task  F,  build  HE  system,  took  less  time  according  to  the  network  diagram 
because  it  was  being  designed  as  the  EM  and  ICE  systems  were  being  designed.  This  is 
more  of  an  artifact  of  the  network  diagram  and  the  definition  of  dependent  and  parallel 
tasks.  The  HE  system  could  not  be  built  without  the  ICE  or  EM  system  and  many  issues 
found  while  building  the  HE  system  would  cause  redesigns  of  the  EM,  ICE  or  both 
systems.  The  duration  of  task  G,  integrate  AFIT 1,  was  just  below  the  lower  end  of  the 
projected  duration.  Once  the  airframes  were  delivered,  Co-Operative  Engineering 
Services  Inc.  (CESI)  was  able  to  get  the  system  ready  for  taxi  test  as  planned.  The 
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extensive  experience  of  CESI  in  flying  hobby  aircraft  assisted  in  keeping  this  task  under 
schedule.  Task  I,  taxi  test  AFIT 1,  took  a  minimum  amount  of  time  because  integration  of 
AFIT  2  was  being  competed  the  morning  of  the  taxi  test,  and  the  taxi  test  was 
accomplished  in  one  day.  Task  L,  AFRL  flight  test  approval,  took  a  minimum  amount  of 
time;  AFRL  decided  that  AFRL  flight  test  approval  was  not  required  since  AFRL  was  not 
directly  funding  the  flight  test.  The  fact  that  this  task  could  be  accomplished  in  parallel 
with  another  task  also  assisted  in  keeping  it  off  the  critical  path. 

The  duration  of  tasks  C,  E,  M,  N,  and  O  fell  within  projected  timeframe.  The  HE- 
RPA  development  team  correctly  predicted  that  task  C,  build  airframes,  would  take 
longer  than  expected.  Fortunately,  the  airframe  that  was  delivered  worked  and  was  able 
to  support  the  required  test  objectives.  Task  E,  bench  test  ICE  system,  stayed  within  the 
expected  range.  Again,  this  is  more  of  an  artifact  of  the  network  diagram.  Two  ICE 
engines  were  damaged,  one  permanently,  during  bench  testing  resulting  in  a  redesign  of 
the  ICE  system.  The  redesign  is  captured  in  the  ICE  system  build  time  and  not  in  the  ICE 
test  time.  Many  hours  were  spent  in  the  lab  testing  different  configurations  of  the  HE 
system  with  the  ICE  running  to  see  if  the  ICE  system  would  work  while  integrated  as  a 
part  of  the  HE  system  as  a  whole. 

Task  M,  bench  test  AFIT  2,  did  not  take  a  long  time.  This  was  likely  due  in  part 
to  the  learning  curve.  The  bench  testing  of  the  integrated  system  was  similar  to  the  bench 
test  of  the  HE  system  but  it  included  the  airframe  and  the  propeller.  Task  N,  taxi  test 
AFIT  2,  also  stayed  within  schedule.  Having  the  prior  experience  of  taxi  testing  AFIT  1 
and  extensive  bench  tests  of  AFIT  2  assisted  in  clarifying  and  accomplishing  the  taxi  test 
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objectives  that  were  accomplished.  Task  O,  flight  test  AFIT  2,  also  took  as  much  time  as 
expected.  The  motivation  to  complete  the  flight  test  prior  to  graduation  assisted  in 
making  sure  everything  was  ready  to  go  for  flight  test  pending  acceptable  flight  weather. 
Task  O  remains  partially  completed  since  AFIT  2  crashed  in  flight  test  and  never  flew.  It 
still  remains  to  be  seen  if  the  HEPS  can  provide  enough  thrust  to  get  AIFT  2  airborne. 

All  HEPSs  were  functioning  properly  when  the  landing  gear  assembly  broke  and  a  wheel 
came  off  during  takeoff. 

Tasks  A,  B,  D,  H,  J,  and  K  took  longer  than  the  maximum  expected  amount  of 
time  to  complete.  Task  A,  build  EM  system  and  task  B,  build  the  ICE  system  were 
accomplished  in  parallel.  Some  delays  that  could  be  attributed  to  other  tasks  were 
included  in  the  delay  for  tasks  A  and  B  since  the  network  diagram  is  not  set  up 
iteratively.  Issues  in  later  tasks  that  resulted  in  rework  of  earlier  tasks  are  charged  to  the 
earlier  task.  It  could  be  argued  that  some  of  the  delays  in  tasks  A  and  B  are  due  to  the 
heavier  class  schedule  during  this  period  but  a  lighter  class  schedule  would  not  have 
shortened  the  fabrication  time  of  many  of  the  parts  built  during  tasks  A  and  B.  In  spite  of 
a  heavy  class  schedule,  Ausserer  [12]  directed  the  interns  in  development  of  HE  system 
components. 

Task  D,  bench  test  EM  system  took  one  day  longer  to  complete  than  the  upper 
bound  of  the  projected  duration.  This  timeframe  does  not  include  much  of  the  rework 
that  was  done  during  the  EM  system  development.  Task  H,  bench  test  HE  system,  was 
delayed  and  some  of  the  delay  could  be  attributed  to  the  iterative  behavior  of  testing, 
which  is  not  captured  by  the  diagram.  Including  the  iterative  nature  of  the  project  with  the 
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network  diagram  would  not  have  sped  up  the  project  completion  and  would  not  have 
changed  what  appears  on  the  critical  path,  it  would  have  only  changed  the  accounting  of 
when  tasks  were  completed. 

Task  J,  integrate  AFIT  2,  took  longer  than  expected  due  to  the  lack  of 
communication  between  team  members  and  CLMax.  Integration  efforts  were  addressed 
at  the  onset  of  the  project  and  an  extra  fuselage  was  shipped  to  ensure  that  the  avionics 
would  fit.  The  fuselage  did  not  include  the  hinges  or  the  other  hardware  required  for 
integration,  so  the  risk  mitigation  efforts  were  ineffective  in  reducing  the  amount  of  time 
required  for  system  integration. 

Task  K,  flight  test  AFIT  1,  was  also  delayed.  Flight  test  delays  were  anticipated 
due  to  the  high  level  of  coordination  required  between  CESI  support  contractors,  HE- 
RPA  team  members,  Camp  Atterbury  scheduling,  advisors,  and  weather.  There  was  a 
delay  in  coordinating  an  acceptable  flight  test  date  for  AFIT  1 .  Since  AFIT  1  was  not  on 
the  critical  path,  it  did  not  delay  the  project.  Ausserer,  who  was  primarily  working  on  the 
HEPS  development,  did  not  attend  the  AFIT  1  flight  test  and  continued  working  on  the 
HEPS  development. 
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Figure  42:  HE-RPA  network  calculations 


Figure  42  shows  how  long  the  project  would  take  if  the  durations  from  the  likely 
column  in  Table  13  were  used,  and  is  repeated  from  Chapter  III  for  ease  of  reference. 
Figure  43  shows  how  long  the  project  actually  took  by  using  the  durations  in  the  actual 
column  from  Table  13  to  calculate  the  network  duration  as  well  as  the  start,  finish,  and 
slack  times.  The  project  lasted  56.6  weeks.  Not  one  of  the  100  trials  in  the  Monte  Carlo 
simulation  took  56.6  weeks.  The  average  pass  through  the  Monte  Carlo  simulation  took 
38.2  weeks  to  accomplish  with  a  standard  deviation  of  4.3  weeks.  The  actual  project 
duration  of  56.6  weeks  is  4.3  standard  deviations  above  the  average. 
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The  average  of  the  team  members’  approximate  minimum,  likely,  and  maximum 
task  durations  were  used  to  generate  triangle  distributions  for  each  task  in  the  network 
diagram.  The  triangle  distribution  was  selected  because  it  can  compensate  for  a  high 
level  of  uncertainty.  If  the  team  member  minimum,  likely,  and  maximum  duration 
approximations  were  accurate,  then  it  would  be  almost  impossible  for  the  project  to  take 
56.6  weeks  to  accomplish.  It  is  almost  certain  that  the  projections  were  not  accurate  and 
that  the  long  schedule  duration  is  due  more  to  the  team  not  understanding  the  entire 
schedule  risk  of  each  task.  Prior  experience  levels  of  the  team  members  could  have  been 
used  to  make  adjustments  to  the  task  estimations  Additionally,  it  would  not  be  accurate 
to  say  that  the  team  was  delayed  due  to  bad  weather  on  account  of  the  unseasonably 
warm  weather  experienced  over  the  fall  and  winter  of  2011-2012.  Given  the  lack  of 
experience  of  the  team  on  similar  projects,  the  inaccuracies  of  the  schedule  predictions 
are  less  surprising 
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4.11.  Results  Summary 


By  using  a  tailored  SE  approach,  the  HE  development  team  was  able  to  develop 
and  test  two  comparable  airframes.  The  development  of  AFIT  1  assisted  in  the 
development  of  AFIT  2  and  served  as  a  baseline  for  comparisons  between  AFIT  1  and 
AFIT  2.  Some  valuable  lessons  were  learned  and  some  useful  data  was  gathered,  even 
though  the  HE-RPA  development  team  was  not  able  to  fly  AFIT  2. 
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V  Conclusions  and  Recommendations 


5.1.  Chapter  Overview 

This  chapter  begins  by  revisiting  the  overarching  research  objectives  and 
discussing  the  findings  in  order  to  provide  a  concept  evaluation  for  the  HE-RPA  and 
inform  a  decision  maker.  An  evaluation  is  then  made  on  the  tailored  SE  approach  and  its 
application  in  this  effort.  Finally,  recommendations  for  future  work  are  discussed. 

5.2.  Research  Objectives 

5.2.1.  Does  current  HE  technology  exists  as  a  viable  option  for  a  small  RPA  in 
a  military  application? 

Current  HE  technology  has  not  yet  developed  sufficiently  to  be  reliably  used  in 
small  military  RPA  operations.  As  captured  by  Ausserer  [12],  the  prototype  HE-RPA 
developed  as  part  of  this  research  required  a  high  level  of  detailed  system  knowledge  in 
order  to  get  all  of  the  components  functioning  properly  prior  to  flight  test.  Although 
bench  and  ground  testing  were  deemed  successful,  the  HE-RPA  failed  to  demonstrate  its 
potential  capabilities  in  flight  due  to  hardware  failures  unrelated  to  the  HEPS. 
Additionally,  ground  and  technical  support  requirements  for  the  prototype  HE-RPA  far 
exceed  the  man-portable/ATV  transportable  RPA  system  presented  in  the  CONOPs. 
Human  system  integration  efforts  were  not  a  priority  for  this  effort,  making  the  HE-RPA 
system  suboptimal  as  a  useful  military  capability.  Other  problematic  issues  such  as 
EM/ICE  alignment  and  EMI  were  also  observed.  However,  the  technology  is  mature 
enough  to  warrant  further  investigation  and  development  as  a  partial  solution  to  the 
aforementioned  capability  gap. 
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5.2.2.  Is  an  airframe  optimized  for  an  HEPS  airworthy? 


Based  on  the  bench  testing,  taxi  testing,  and  flight  testing  of  AFIT  1  in  restricted 
air  space,  the  basic  airworthiness  of  the  airframe  has  been  established.  Specifically,  the 
12-ft  wingspan  configuration  at  the  nominal  weight  of  35-lbs  was  flown  successfully  with 
acceptable  performance.  An  integrated  autopilot  system  was  able  to  successfully  control 
and  navigate  the  airframe.  The  AFIT  1  flight  tests  also  confirmed  an  efficient  design 
with  a  predicted  loiter  time  exceeding  7  hours.  Although  it  was  not  the  fully  optimized 
configuration  presented  by  Hannon  [1 1],  it  is  believed  that  a  configuration  closer  to  the 
optimized  design  would  only  enhance  the  performance.  Successful  flight  tests  will  be 
required  prior  to  airworthiness  certification  in  other  than  restricted  airspace. 

It  was  observed  in  ground  testing  that  EMI  resulting  from  integration  of  the  HEPS 
would  result  in  uncontrollable  conditions  in  flight.  The  EMI  caused  servo  motors 
controlling  the  throttle  and  the  control  surfaces  to  exhibit  excessive  un-commanded 
movements.  This  issue  is  identifiable  prior  to  HE-RPA  flight  and  could  be  resolved  in 
the  future  with  additional  wire  shielding  or  rerouting  of  internal  wires. 

A  critique  on  airframe  robustness  is  also  warranted.  While,  the  airframe  geometry 
proved  airworthy,  the  construction  materials  and  assembly  techniques  lacked  robustness 
for  any  purpose  other  than  a  prototype  airframe.  Specifically,  the  wing  and  aft  fuselage 
attachment  technique  relied  on  an  aluminum  hinge-pin  configuration  sandwiched 
between  a  fiberglass  and  foam  inner  and  outer  fuselage.  This  resulted  in  a  weakened 
fuselage  structure  and  repetitive  realignment  and  repair  issues.  The  hinge-pin  design  also 
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exacerbated  flexibility  issues  within  the  structure  and  made  it  more  difficult  than 
warranted  to  access  internal  components 

As  demonstrated  in  taxi  test  but  not  flight  test,  the  dual  ICE  and  EM  design 
provides  an  inherent  airworthiness  advantage.  If  one  propulsion  component 
malfunctions,  the  other  could  be  used  to  safely  land  and  recover  the  aircraft.  This 
potential  does  not  exist  for  an  RPA  with  a  single  propulsion  system. 

5.2.3.  Can  an  HE  control  strategy  be  developed  and  implemented  into  the 

RPA? 

Two  potentially  viable  control  strategies  were  developed  but  not  demonstrated  for 
the  HE-RPA.  The  first  relied  on  a  self-contained  PIC32  microcontroller  implementing 
custom  control  logic.  The  second  relied  on  custom  throttle  split  code  implemented  via 
the  Virtual  Cockpit  software  and  Kestrel  autopilot.  Further  testing  is  required  to  verify 
that  the  chosen  control  strategy  is  acceptable.  The  control  logic  for  the  flight  control 
surfaces  does  not  change  between  the  ICE-RPA  and  the  HE-RPA.  The  key  difference  is 
that  the  HE-RPA  has  several  different  throttle  modes  that  were  demonstrated  during 
bench  testing  and  taxi  testing  but  have  yet  to  be  shown  in  flight  test.  Based  on  the  bench 
and  taxi  testing  results,  it  is  reasonable  to  assume  that  if  the  HE-RPA  has  enough  thrust  to 
get  airborne,  then  the  control  strategy  will  work  for  all  throttle  modes  that  command 
enough  thrust  to  keep  the  HE-RPA  airborne. 

5.2.4.  Can  an  HE  system  can  be  successfully  integrated  into  a  small  RPA? 

The  current  research  demonstrated  that  the  HE  system  can  be  successfully 
integrated  into  the  RPA.  The  current  research  demonstrated  one  alternative  to  integrating 
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an  HE  system  into  an  RPA  and  discussed  several  alternative  methods.  An  alternate 
microcontroller  could  also  be  developed  and  used  to  automate  the  HE  mode  control. 
Additionally,  an  electric  starter  could  be  integrated  into  the  system  to  support  aerial 
restart  of  the  ICE. 

5.2.5.  Does  an  HEPS  improve  RPA  flight  endurance  over  an  RPA  equipped 
with  a  non-HE system? 

This  effort  was  not  able  to  successfully  demonstrate  that  the  endurance  of  an  HE- 
RPA  exceeds  that  of  an  RPA  with  a  non-HEPS.  Glassock  [23]  proposed  that  an  HE- 
PRA  could  be  built  with  an  electric  motor  that  is  designed  to  be  used  only  during  takeoff 
to  decrease  the  required  size  of  the  ICE.  Such  an  RPA  could  conceivably  fly  longer  than 
an  RPA  powered  by  an  ICE.  Further  research  is  required  to  determine  the  potential  of 
such  a  system. 

An  HEPS  could  be  used  to  exceed  the  flight  endurance  of  the  traditional  ICE 
powered  RPA  if  a  control  scheme  that  keeps  the  ICE  throttle  position  constant  during 
cruise  and  uses  an  EM  to  make  the  minor  adjustments  required  to  maintain  steady  level 
flight.  Such  a  capability,  referred  to  as  the  EM  driver  (EM  boost)  mode  was  successfully 
implemented  and  demonstrated  during  bench  and  ground  testing  of  AFIT  2.  The  key 
difference  between  this  recommended  configuration  and  the  configuration  implemented 
on  AFIT  2  is  that  it  would  have  fewer  batteries.  AFIT  2  used  several  batteries  because 
the  intent  was  to  develop  a  near-silent  loiter  capability  with  a  greater  dependence  on  EM 
operation.  If  the  intent  were  to  increase  the  duration  of  the  cruise  mode,  then  the  ICE 
throttle  position  would  be  set  at  the  optimal  position  and  any  excess  power  generated 
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would  be  used  to  recharge  the  batteries  and  any  additional  power  required  would  be 
provided  by  the  EM.  Further  research  is  required  to  determine  the  potential  of  such  a 
system. 

5.2.6.  Does  the  HE  system  results  in  a  reduced  acoustic  signature? 

A  reduction  in  the  HE-RPA  acoustic  signature  was  not  sufficiently  demonstrated. 
Further  research  is  required  to  detennine  the  potential  reduction  in  acoustic  signature  by 
the  HE-RPA.  The  intent  was  to  gather  baseline  in-flight  acoustic  data  using  AFIT  1  and 
then  compare  the  results  to  in-flight  acoustic  data  collected  using  AFIT  2  (the  HE-RPA). 
However,  the  in-flight  acoustic  data  collected  from  AFIT  1  was  deemed  invalid  due  to 
excessive  wind  noise.  Additionally,  acoustic  testing  of  AFIT  2  did  not  occur  due  to  an 
aircraft  failure  during  takeoff.  Acoustic  testing  conducted  on  the  ground  with  AFIT  1  did 
identify  a  potential  reduction  in  the  acoustic  signature  of  any  RPA,  not  just  the  HE-RPA, 
by  using  an  appropriately  sized  carbon  fiber  or  equally  stiff  propeller  with  a  higher  blade 
count. 


5.2. 7.  Does  the  HE-RPA  meet  capability  requirements  set  forth  in  a  CONOPS? 


The  capability  requirements  set  forth  in  the  CONOPS  currently  include: 


Austere  Employment  Capability; 


Effective  Multi-Mode  Operation; 


Rapid  Ingress  and  Egress  Capability; 


•  Sustained  Near-Silent  Loiter 


Capability; 


•  Minimally  Complex  Operator 
Interface; 

•  Adaptable  ISR  Payload  Capability. 
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Currently,  the  “as-built”  configuration  represented  by  AFIT  2,  lacks  the  capability 
to  be  employed  in  an  austere  environment.  The  HE-RPA  does  not  currently  possess  the 
robustness,  transportability,  or  minimal  logistical  footprint  required  for  austere 
employment. 

The  rapid  ingress  and  egress  capability  is  tied  to  ICE  only  operation  per  the  HE- 
RPA  CONOPS.  Flight  tests  conducted  with  AFIT  1  and  bench  testing  conducted  with 
AFIT  2  indicates  that  the  HE-RPA  does  possess  the  necessary  ICE  reliability, 
controllability,  and  airframe  perfonnance  necessary  to  achieve  this  capability.  The  HE- 
RPA  also  has  the  potential  to  perfonn  a  faster  ingress  or  egress  as  required  by  operating 
in  dual  mode. 

Bench  testing  indicated  that  the  HE-RPA  has  the  potential  to  sustain  near-silent 
loiter  operations  via  employment  of  the  regeneration  capability.  Mode  switching 
between  the  ICE  only  mode,  EM  mode  with  an  idle  ICE,  and  the  regeneration  mode  was 
successfully  demonstrated.  However,  without  a  mid-air  ICE  restart  capability  the  ability 
to  operate  in  pure  EM  only  mode  and  transition  into  any  other  mode  was  not 
demonstrated.  Currently,  the  “as-built”  configuration  would  only  partially  meet  this 
capability.  While  not  quantitative,  the  acoustic  measurement  flight  test  with  AFIT  1  did 
indicate  that  the  HE-RPA  has  the  potential  to  operate  with  a  near-silent  loiter  capability  at 
specific  altitudes  even  with  noise  associated  with  the  ICE.  The  EM  only  mode  would 
serve  to  enhance  the  capability. 

Ground  testing  and  bench  testing  with  AFIT  2  demonstrated  the  mode  switching 
capability  of  the  HE-RPA.  Although  the  prototype  lacked  the  ICE  engine  restart 
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capability  and  hence  the  ability  to  switch  out  of  EM  only  mode,  the  mode  switching  logic 
implemented  via  the  Virtual  Cockpit  ground  station  software,  the  Kestrel  autopilot,  and 
the  electric  motor  control  operated  reliability  with  only  minor  operator  induced  problems. 
The  more  capable  and  self-contained  implementation  of  the  PIC32  microcontroller  could 
further  enhance  the  capability  and  reduce  operator  workload,  better  satisfying  the  desired 
capabilities  in  the  CONOPS. 

Even  though  the  prototype  HE-RPA  operator  interface  GUI  was  an  unplanned 
addition,  the  interface  remained  relatively  simple  and  would  meet  the  intended  capability 
set  forth  in  the  CONOPS.  The  tested  configuration  only  required  the  operator  to  click  a 
set  of  radio  buttons  to  switch  between  operational  modes.  As  part  of  the  development 
effort,  an  additional  set  of  boost  mode  throttle  settings  were  implemented.  These  would 
not  be  needed  on  an  operational  configuration.  In  the  “as-built”  configuration,  the  HE 
mode  selection  would  ideally  be  transparent  to  the  operator. 

The  CONOPS  presented  a  requirement  for  an  HE-RPA  that  could  operate  with  a 
myriad  of  ISR  payloads.  The  AFIT  2  configuration  intended  for  flight  testing  had  a  gross 
weight  of  35-lbs,  which  was  determined  to  be  the  airframe  limit  on  AFIT  1 .  Although  the 
prototype  HE-RPA  only  had  capacity  for  a  small  payload,  the  power  distribution  and 
regeneration  capability  of  the  HEPS  would  facilitate  the  use  of  numerous  payloads. 
Robust  airframe  construction  allowing  for  the  optimized  15 -ft  wingspan  and  50-lb  gross 
weight  would  leave  considerable  margin  for  numerous  payloads.  The  HE-RPA  concept 
could  successfully  fulfill  the  ISR  payload  capability. 
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In  total,  this  effort  focused  on  rapidly  developing  an  HE-RPA  prototype  in  order 
to  evaluate  it  against  a  CONOPS.  As  built,  the  HE-RPA  failed  to  demonstrate  any  of  the 
in-flight  capabilities  set  forth  in  the  CONOPS.  However,  bench  testing  and  ground 
testing  confirmed  that  the  HE-RPA  does  possess  some  of  the  desired  non-flying  specific 
capabilities.  Successful  bench  and  ground  testing  with  the  HE-RPA  indicate  that  the 
system  has  the  potential  to  satisfy  a  majority  of  the  capabilities.  With  additional  time  to 
implement  the  design  enhancements  noted  by  Ausserer  [12]  and  development  of  a  robust 
variant  of  the  airframe,  the  full  set  of  capabilities  could  be  achieved. 

5.3.  Evaluation  of  Tailored  Systems  Engineering  Process 

Using  a  streamlined  SE  process,  the  HE-RPA  development  team  was  able  to 
rapidly  develop  a  new  airframe  prototype  with  two  very  different  propulsion  systems  in 
13  months.  The  streamlined  systems  engineering  process  assisted  the  team  in 
appropriately  executing  and  scoping  the  project  while  maintaining  visibility  of  high  level 
project  objectives  given  predicted  and  unpredicted  project  risks. 

By  tailoring  the  SE  process  as  the  project  continued,  the  team  was  able  to 
accomplish  three  objectives,  each  with  a  moderate  to  high  level  of  technical  risk.  The 
team  was  able  to  develop  and  fly  a  new  airframe,  develop  an  HEPS,  and  integrate  an 
HEPS  into  a  new  airframe. 

The  HE-RPA  development  team  initially  discussed  creating  a  SEP  by  filling  in 
the  blanks  of  an  existing  SEP  template  but  detennined  that  a  generic  template  would 
neither  provided  added  value  to  the  project,  nor  aid  in  the  development  of  a  useful 
tailored  SE  process.  Instead,  the  team  decided  to  initially  start  with  an  informal  SEP 
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consisting  of  two  bulleted  lists  and  a  simple  schedule.  The  infonnal  SEP  was  sufficient 
to  scope  and  direct  the  work  during  the  early  stages  of  the  project.  As  the  project 
continued,  formal  documents  such  as  the  TEMP  were  added  as  deemed  necessary  until 
the  SEP  transformed  into  what  became  Chapter  III  of  this  thesis  and  the  associated 
appendices. 

The  tailored  SE  process  used  and  advocated  in  the  current  research  did  not 
include  completing  SE  documents  for  the  sake  of  completing  SE  documents,  or  as  a 
means  to  convince  a  higher  authority  that  the  project  was  in  good  standing  and  that  the 
team  members  were  using  good  SE  discipline.  If  the  team  were  required  to  develop 
every  SE  artifact  required  for  acquisition  by  the  DoD  ,  there  would  have  been  much  less 
time  to  dedicate  to  project  execution.  The  process  also  did  not  include  hiring  support 
contractors  to  complete  SE  documentation.  A  lack  of  SE  knowledge  and  discipline 
within  the  team  could  not  have  been  remediated  by  either  hiring  a  contractor  to 
accomplish  all  of  the  SE  documentation  required  by  the  DoD  or  by  filling  in  existing  SE 
templates. 

The  principles  of  maintaining  an  SE  approach  that  is  event  driven,  has  well 
defined  entry  and  exit  criteria,  uses  only  SE  artifacts  that  add  value  to  the  project,  and 
allows  a  fonnal  and  informal  format  for  SE  artifacts  proved  useful  and  sufficient  for 
tailoring  the  SE  process  to  a  rapid  prototype  development  project. 

5.4.  Information  for  a  Decision  Maker 

Ultimately,  efforts  such  as  the  presented  rapid  prototype  development  and  concept 
evaluation  of  the  HE-RPA  would  be  presented  to  a  decision  maker.  A  decision  maker 
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would  need  a  clear  understanding  of  the  current  development  status,  required  effort 
remaining,  and  potential  benefits.  In  order  to  make  a  decision  on  the  continuation  of 
development  efforts  for  the  HE-RPA,  the  following  questions  were  established  at  the 
project’s  inception  and  answered  throughout  prototype  development  and  concept 
evaluation. 

5.4.1.  What  additional  efforts  are  needed  to  get  to  the  “as  intended ” 

configuration? 

Captured  by  the  SV-8,  Appendix  F,  in  the  systems  architecture,  the  remaining 
effort  required  to  get  to  the  “as-intended”  configuration  consists  of  refined  development 
and  reliability  enhancements  of  the  HEPS  and  robustness  enhancements  to  the  airframe. 
Additionally,  operationally  representative  systems  would  need  to  go  through  a  battery  of 
operationally  representative  tests  in  order  to  verify  operability  by  standard  users  and  a 
realization  of  military  or  commercial  benefits. 

5. 4. 2.  What  are  the  technology  gaps? 

The  primary  technology  gaps  are  captured  by  Ausserer  [12]  and  include  limited 
capabilities  of  electric  motor  controllers  and  propeller  and  acoustic  measurement  and 
reduction  efforts.  While  not  a  technology  gap,  the  required  fabrication  tolerances  of  the 
HEPS  would  need  to  be  fully  understood  by  future  HEPS  developers. 

5.4.3.  How  effective  will  it  be? 

While  no  HE-RPA  system  performance  was  demonstrated  in  flight,  bench  and 
ground  testing  of  AFIT  2,  along  with  flight  test  results  from  AFIT  1  indicate  that  a  robust 
system  with  similar  performance  could  fulfill  the  2  to  8-hour  capability  gap  that  currently 
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exists  between  electric  powered  RPAs  and  gasoline/diesel  powered  RPAs.  The  power 
distribution  of  the  HE-RPA,  AFIT  2,  could  potentially  also  accommodate  a  myriad  of 
ISR  sensors.  Additionally,  results  indicate  that  AFIT  1,  equipped  with  a  quiet  propeller, 
may  also  provide  the  anticipated  endurance  and  acoustic  benefits  of  the  AFIT  2  with 
lower  risk  and  reduced  complexity. 

5.4.4.  Will  it  provide  m  i I / tary  uti lity? 

A  robust  and  transportable  variation  of  the  system  could  provide  military  utility 
by  reliably  fulfilling  the  previously  identified  capability  gap. 

5.4.5.  Who  are  the  users  and  stakeholders? 

As  captured  by  the  systems  architecture,  the  users  of  the  HE-RPA  system  would 
be  the  operators  and  support  crew  personnel.  Stakeholders  would  be  recipients  of  the 
collected  ISR  data  such  as  a  field  unit  or  members  of  a  command  and  control  function. 

5.4. 6.  Where  could  this  concept  be  used  successfully? 

Although  the  efforts  presented  herein  primarily  focused  on  the  military 
application  presented  by  the  CONOPS,  an  RPA  system  with  the  anticipated  endurance 
and  near-silent  loiter  capabilities  of  the  HE-RPA  developed  as  part  of  this  research  could 
be  used  for  several  other  missions.  Missions  such  as  homeland  defense,  border  patrol, 
agricultural  health  surveillance,  law  enforcement,  and  oceanic  surveillance  could  benefit 
from  use  of  the  HE-RPA. 
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5.5.  Recommendations  for  Future  Work 


More  research  and  development  is  required  to  fully  evaluate  and  quantify  the 
concept  of  using  an  HE-RPA  to  fill  the  existing  military  capability  gap  discussed  in 
Chapter  I.  The  SV-8  depicted  in  Appendix  F  could  be  used  to  develop  the  “as-intended” 
configuration.  If  capability  trade  space  is  needed  to  get  to  the  “as-intended” 
configuration,  then  the  system  functions  identified  in  Table  3  should  be  examined.  The 
HE-RPA  development  team  was  unsuccessful  in  demonstrating  the  capability  of  the  HE- 
RPA  to  fly  due  to  damage  to  AFIT  2  caused  during  takeoff.  However,  component  and 
system  performance  demonstrated  on  the  ground  and  on  the  bench,  along  with  baseline 
airframe  flight  testing,  indicate  that  the  development  of  a  fully  capable  HE-RPA  system 
is  attainable  in  the  near  future. 

This  team  development  effort  expanded  the  HE-RPA  body  of  knowledge. 
However,  the  HE-RPA  concept  is  still  in  its  infancy  and  requires  further  development  to 
detennine  the  military  suitability  of  the  different  HE  modes,  configurations,  and  control 
schemes.  In  addition  to  further  development  of  the  HEPS  and  a  robust  airframe,  further 
research  is  required  to  reduce  the  acoustic  signature  of  propellers  suitable  for  the  small 
HE-RPA  concept. 

Further  pursuit  of  the  near-silent  loiter  capability  would  require  research  aimed  at 
comparing  results  of  acoustic  measurements  gathered  from  the  HEPS  in  the  lab 
environment  to  acoustic  measurements  gathered  from  an  HE-RPA  in  flight.  The  purpose 
of  this  research  would  be  to  determine  the  ability  to  predict  acoustic  flight  results  based 
on  acoustic  data  gathered  in  a  lab  environment. 
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One  aspect  of  this  research  was  to  conduct  a  comparative  acoustic  analysis 
between  AFIT  1  and  AFIT  2.  Comparisons  between  AFIT  1  and  AFIT  2  would  not  be 
meaningful  outside  the  scope  of  this  research  due  to  general  inconsistencies  in  measuring 
dynamic  acoustics  in  a  universally  accepted  way.  The  use  of  an  SPL  meter  and  the  A- 
weighting  scale  to  measure  dynamic  RPA  systems  or  propellers  is  questionable  given  the 
origination  of  this  measuring  technique.  Without  commonly  employed  and  accepted 
standards  for  measuring  acoustics,  it  would  be  difficult  to  compare  the  acoustic  noise  of 
AFIT  1  and  AFIT  2  with  other  aircraft  not  included  in  this  research.  An  investigation 
into  acoustic  measuring  standards  and  techniques  should  be  undertaken. 

5.6.  Summary 

By  following  a  tailored  SE  process,  the  HE-RPA  development  team  was  able  to 
rapidly  design,  develop,  and  evaluate  a  prototype  HE-RPA  and  a  baseline  ICE  powered 
RPA.  The  development  team  was  able  to  accomplish  a  majority  of  the  objectives 
established  during  the  initiation  of  this  research.  The  team  was  able  to  demonstrate  the 
potential  of  the  HE-RPA  in  fulfilling  the  current  endurance  and  logistical  capability  gaps 
that  exist  between  the  employment  of  electric  powered  RPAs  and  fossil  fuel  powered 
RPAs.  The  team  was  not  able  to  accomplish  all  of  the  desired  test  events,  but  was  able  to 
accomplish  a  vast  majority  of  test  events  by  first  accomplishing  low  risk  test  events. 
Further  research  in  the  area  of  HE-RPA  development  is  required  to  demonstrate  the 
potential  of  the  “as-intended”  configuration  discussed  in  this  research.  Further  research 
is  also  required  to  mitigate  the  acoustic  signatures  of  RPA  propellers. 
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Appendix  A.  Concept  of  Operations 


HYBRID-ELECTRIC  RPA 


CONOPS 
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19  July  2011 


Section  I  -  Issue 

A.  Problem  Statement 

In  the  past  decade,  the  US  Military  and  Department  of  Homeland  Security  have  seen  the 
numerous  benefits,  and  have  come  to  rely  upon,  Remotely-Piloted  Aircraft  (RPA)  and 
their  role  in  combat  and  information  operations.  Fixed  wing  platforms  such  as  the 
Predator  (MQ-1)/Reaper  (MQ-9)  and  the  Global  Hawk  (RQ-4)  have  tremendous 
capabilities  but  they  are  low-density/high-value  (LDHV)  assets;  making  their  availability 
limited  to  all  but  the  most  critical  missions.  As  a  result,  there  has  been  rapid  growth  in  the 
area  of  smaller,  unit  controlled,  RPAs.  These  are  small  (less  than  30  lbs)  to  medium 
(between  30  and  500  lbs)  sized  air  vehicles  capable  of  being  operated  by  small  forward 
deployed  units.  These  vehicles  provide  critical  Infonnation,  Surveillance,  and 
Reconnaissance  (ISR)  data  before,  during,  and  after  ground  operations. 

However,  there  are  two  critical  issues  that  limit  the  usefulness  of  these  small  to  medium 
sized  RPAs.  In  order  to  achieve  a  desired  standoff  capability  or  a  long 
endurance/loitering  capability,  the  vehicles  must  be  equipped  with  an  Internal 
Combustion  Engine  that  burns  gasoline  or  diesel  fuel.  These  fuel  burning  engines  are 
both  noisy  to  operate  and  cumbersome  to  support  during  combat  operations;  limiting  their 
use  at  low  altitudes  and  often  requiring  dedicated  support  facilities.  On  the  other  hand, 
smaller  battery  powered  electric  RPAs  are  considerably  quieter  and  more  efficient  in  their 
energy  utilization.  In  general,  they  are  more  portable,  easier  to  operate,  require  less 
support  and  maintenance,  and  can  be  flown  at  lower  altitudes.  The  drawback  is  their 
limited  endurance  and  limited  payload;  requiring  their  employment  considerably  closer  to 
the  target  area  than  their  fuel  burning  counterparts.  The  challenge  is  to  create  and  utilize 
an  RPA  with  the  endurance  benefits  of  an  internal  combustion  powered  vehicle  but  with 
the  reduced  acoustic  signature,  reduced  logistic  support,  and  low  altitude  operations  of  an 
electric  powered  vehicle. 


B.  Overarching  Vision 

To  deliver  timely  and  relevant  ISR  to  forward  deployed  ground  based  units  via  the  use  of 
a  remotely-piloted  aircraft  encompassing  the  benefits  of  both  fuel  burning  and  electric 
powered  remotely-piloted  air  vehicles  while  operating  from  a  safe  standoff  location. 


C.  Purpose  of  the  CONOPS 
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This  document  describes  operational  employment  scenarios  whereby  military  or 
homeland  security  personnel  could  realize  the  unique  endurance  and  acoustic  benefits 
offered  by  a  remotely-piloted  aircraft  (RPA)  powered  by  a  hybrid-electric  propulsion 
system.  The  system  utilizes  an  integrated  semi-autonomous  propulsion  control  strategy 
to  maximize  mission  effectiveness.  A  common  command,  control,  and  communications 
interface  will  be  utilized,  enhancing  the  system  flexibility  and  making  the  system 
adaptable  to  a  wide  variety  of  situations  and  environments.  The  system  will  have  a 
versatile  payload  configuration  allowing  for  multiple  ISR  configurations  or  unique 
payload  employment. 


D.  SCOPE 

This  document  is  intended  to  be  a  [Joint  Component]  Enabling  Concept  and  is  written  at 
the  operational-level.  This  document  supports  the  fundamental  guidance  and  overarching 
concept  for  NATO  operations  detailed  in  the  Strategic  Concept  of  Employment  for 
Unmanned  Aircraft  Systems  in  NATO  2010. 

Specifically,  the  Hybrid-Electric  RPA  CONOPS  will  describe  the  anticipated  utilization 
and  supporting  context  required  to  sustain  persistent  and  covert  RPA  operations  detailed 
in  the  United  States  Air  Force  Posture  Statement  2011  for  Global  Integrated  Intelligence 
Surveillance  Reconnaissance  (ISR). 


Section  II  -  Overview 
A.  Synopsis 

A  hybrid-electric  powered  RPA  will  provide  forward  deployed  ground  based  units  the 
capability  to  conduct  sustained,  low  altitude,  ISR  operations  from  a  safe  standoff  distance 
with  minimal  logistical  support.  Specifically,  the  use  of  the  hybrid-electric  RPA  will 
allow  operators  to: 

•  Rapidly  setup  and  deploy  RPA  system  from  austere  location 

•  Quickly  ingress/egress  to/from  the  target  area  utilizing  internal 
combustion  engine 

•  Covertly  loiter  over  a  desired  target  area  using  electric  power 

•  Utilize  payloads  optimized  for  low  altitude  operations 

•  Monitor  ISR  date  from  safe  standoff  distance 

•  Regenerate  electrical  stores  for  sustained  surveillance  operations 

•  Provide  timely  ISR  data  for  ongoing/future  ground  operations 
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B.  Operational  View  (OV)-l 

The  following  figure  depicts  the  overall  environment  and  operational  phases 
described  in  this  CONOPS.  In  order  to  achieve  outcomes  defined  by  the  vision 
statement  using  a  hybrid-electric  RPA,  the  following  actions  are  necessary. 


Ground  Control  Station 


omnibox 


|  OV-1 :  Hybrid-Electric  UAV  Operational  Concept 


Regeneration  Phase 

/•  X 


.  GPS 


Surveillance  Phase 


Ingress/Egress  Phase 

" 


Ground  Control  Setup  &  Teardown  Phase:  This  phase  encompasses  all  actions 
necessary  to  deploy  the  hybrid-electric  RPA  system  including:  unpacking,  inventory, 
assembly,  function  checks,  mission  planning,  and  launch  and  recovery. 

Ingress/Egress  Phase:  This  phase  utilizes  the  hybrid-electric  propulsion  system, 
operating  in  a  cruise  mode,  to  quickly  transition  to-and-from  the  launch  location  to 
the  target  area.  The  cruise  mode  takes  advantage  of  the  benefits  offered  by  the 
internal  combustion  engine  (ICE)  to  efficiently  and  rapidly  reach  the  target  area  when 
the  additional  noise  of  the  ICE  will  not  be  a  detriment  to  the  mission. 

Surveillance  Phase:  This  phase  utilizes  the  hybrid-electric  propulsion  system, 
operating  in  an  endurance  mode,  to  acquire  surveillance  data  within  the  target  area 
while  minimizing  its  acoustic  signature  and  thereby  the  probability  of  detection.  The 
endurance  mode  utilizes  the  battery  powered  electric  motor  capability  to  loiter  over  a 
target  area  without  the  elevated  noise  levels  produced  by  the  ICE. 
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Regeneration  Phase:  This  phase  utilizes  a  unique  regeneration  capability  offered  by 
the  hybrid-electric  propulsion  system.  The  primary  mission  of  the  RPA  is  to  acquire 
ISR  while  over  the  target  area.  However,  this  requires  prolonged  operation  in  the 
endurance  mode  and  to  date,  current  battery  technology  does  not  support  the  desired 
mission  needs.  The  regeneration  mode  allows  the  HE-RPA  to  transition  to  an  area  (or 
altitude),  where  the  noise  level  of  the  ICE  does  not  impact  the  mission,  and  to  utilize 
the  electric  motor,  now  acting  as  a  generator,  to  recharge  the  battery  packs.  This 
capability  allows  for  prolonged  mission  times  without  having  to  recover  back  to  the 
ground  control  station  for  battery  replacement. 

External  Environment:  The  hybrid-electric  RPA  will  generally  operate  in  austere  and 
hostile  environment  under  a  myriad  of  environmental  conditions.  The  operational 
environment  must  be  capable  of  providing  a  global  positioning  system  signal  as  it 
will  be  the  primary  navigation  aid  for  the  HE-RPA.  Operational  employment  may  be 
dependent  upon  terrain  obstacles  and/or  operational  altitude  as  the  primary  human-to- 
vehicle  communication  pathway  will  be  a  high-frequency  radio  signal.  Line-of-sight 
limitations  will  have  to  be  accounted  for  in  mission  planning. 


C.  Description  of  Military  Challenge 


Currently,  minimally  detectible  assets  capable  of  collecting  persistent  ISR  are  high-value 
low-density  systems.  Forward  deployed  units  desire  the  benefits  provided  by  these  assets 
but  the  units  are  limited  by  availability  and  instead,  must  rely  on  currently  available 
gasoline/dies  el  or  electric  powered  RPAs.  The  hybrid-electric  RPA  is  intended  to  fill  a 
gap  that  exists  between  the  performance  benefits  of  gasoline/dies  el  powered  RPAs  and 
electric  powered  RPAs,  while  still  providing  the  desired  ISR  collection  capability.  The 
hybrid-electric  RPA  is  intended  to  conduct  missions  currently  ill-suited  for  either 
gasoline/diesel  powered  RPAs  or  electric  powered  RPAs.  The  primary  objective  of  the 
hybrid-electric  RPA  is  the  collection  of  timely  ISR  data  with  a  low  probability  of 
detection  by  forward  deployed,  ground  based  operators,  while  main  taining  a  safe 
standoff  distance  from  the  target  area. 


D.  Desired  Effects 

The  desired  effect  is  to  provide  ground  based  units  with  undetected,  timely,  and  enduring 
ISR  data  from  a  safe  standoff  distance  with  minimal  logistical  support. 
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Section  III  -  Context 

A.  Time  Horizon 


This  CONOPS  focuses  on  an  enabling  capability  intended  to  provide  ground  based  units 
with  ISR  data  in  support  of  theater  directed  mission  taskings.  This  CONOPS  provides 
employment  recommendations  for  a  proposed  hybrid-electric  RPA  [system] .  Through 
expanded  operation  and  utilization,  the  recommendations  provided  are  intended  to 
evolve  into  strategic  employment  scenarios  as  best  practices  are  collected  and 
documented.  The  planned  initial  utilization  begins  in  FY12  and  proceeds  into  the 
foreseeable  future. 


B.  Assumptions 

This  CONOPS  assumes  that  the  capability  gap  identified  between  high-density  low- 
volume  ISR  assets,  gasoline/diesel  powered  RPAs,  and  electric  powered  RPA  is  still 
present  and  unresolved.  Additionally,  it  is  assumed  that  airspace  deconfliction  issues  will 
be  resolved  prior  to  each  mission  utilizing  the  hybrid-electric  RPA  as  there  is  no  intent  to 
address  that  specific  issue  within  this  document. 

C.  Risks 

The  following  risks  were  derived  from  a  consortium  of  stake  holders  including,  former 
RPA  operators,  systems  architects,  subject  matter  experts,  system  designers,  and  testers: 

•  Loss  of  RPA  due  to  hostile  detection  and  action 

•  Loss  of  RPA  due  to  broken  communications  link 

•  Loss  of  RPA  due  to  system  malfunction 

•  Loss  of  RPA  due  to  extreme  environmental  conditions 

•  Hostile  detection  of  operator  location 

•  Hostile  acquisition  of  signal  feeds  and/or  control  of  RPA 

•  Loss  of  mission  due  to  unreliability  of  system  components 

•  Loss  of  mission  due  to  system  degradation 

•  Loss  of  RPA  and/or  mission  due  to  lack  of  logistical  resources 

•  Loss  of  RPA  and/or  mission  due  to  lack  of  operator  knowledge 

•  Injury  to  operator  and/or  noncombatants  from  system  operation 

In  response  to  the  identified  risks  associated  with  system  operation,  the  following  risk 
mitigations  were  derived: 

•  Prototype  development 
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•  Spiral  developmen  t  process 

•  Relevant  application  of  systems  architecture  and  test  management 

•  Thorough  utilization  of  SE  practices 

•  Development  and  evaluation  of  acoustic  characteristics  designed  to  mitigate  RPA 
detection  and  loss 

•  Development  of  robust  autopilot  control  strategy 

•  Evaluation  and  documentation  of  maximum  employable  range/altitude  scenario 

•  Development  and  documentation  of  operators  manual  and  emergency  procedures 

•  Evaluation  of  environmental  performance  and  development  of  recommend 
employment  conditions/limitations 

•  Minimization  of  ground  control  and  logistical  support  equipment 

Additionally,  risks  associated  with  system  and  signal  security  are  deemed  acceptable  by 
stake  holders  and  no  associated  mitigation  actions  are  addressed.  The  anticipated  results 
of  risk  mitigation  activities  are  depicted  in  Table  1. 
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Table  14:  Effects  of  Ris 


c  Mitigation 


Risk 

ID 

Risk  Description 

Preliminary  Risk 

Mitigation 

Residual  Risk 

Effect 

Frequency 

Impact 

Effect 

Frequency 

Impact 

l 

Loss  of  RPA  due  to  hostile  detection 
and  action 

Critical 

Seldom 

Low  Risk 

Prototype  design  and  testing 
to  evaluate  detectability 

Marginal 

Seldom 

Low  Risk 

2 

Loss  of  RPA  due  to  broken 

communications  link 

Critical 

Occasional 

Medium  Risk 

Development  of  robust 
autopilot  capability 

Critical 

Seldom 

Low  Risk 

3 

Loss  of  RPA  due  to  system 
malfunction 

Critical 

Occasional 

Medium  Risk 

Spiral  development  to 
improve  reliability 

Critical 

Seldom 

Low  Risk 

4 

Loss  of  RPA  due  to  extreme 

environmental  conditions 

Critical 

Seldom 

Low  Risk 

Development  of  operational 
employment  limits 

Marginal 

Seldom 

Low  Risk 

5 

Hostile  detection  of  operator 
location 

Catastrophic 

Seldom 

Medium  Risk 

Minimization  of  logistical 
support  footprint 

Critical 

Seldom 

Low  Risk 

6 

Hostile  acquisition  of  signal  feeds 
and/or  control  of  RPA 

Catastrophic 

Unlikely 

Medium  Risk 

None 

Catastrophic 

Unlikely 

Medium  Risk 

7 

Loss  of  mission  due  to  unreliability 
of  system  components 

Critical 

Occasional 

Medium  Risk 

Spiral  development  to 
improve  reliability 

Critical 

Seldom 

Low  Risk 

8 

Loss  of  mission  due  to  system 
degradation 

Critical 

Occasional 

Medium  Risk 

Spiral  development  to 
improve  reliability 

Critical 

Seldom 

Low  Risk 

9 

Loss  of  RPA  and/or  mission  due  to 
lack  of  logistical  resources 

Critical 

Occasional 

Medium  Risk 

Minimization  of  logistical 
support  footprint 

Critical 

Seldom 

Low  Risk 

10 

Loss  of  RPA  and/or  mission  due  to 
lack  of  operator  knowledge 

Critical 

Seldom 

Low  Risk 

Development  of  operational 
training  materials 

Critical 

Unlikely 

Low  Risk 

11 

Injury  to  operator  and/or 
noncombatants  from  system 
operation 

Catastrophic 

Seldom 

Medium  Risk 

Development  of  operational 
training  materials  and 
emergency  procedures 

Critical 

Seldom 

Low  Risk 

123 


Section  IV  -  Employment  Concept 


A.  High-Level  Context 


The  high-level  context  that  relates  the  hybrid-electric  RPA  concept  to  achieving  strategic 
objectives  is  centered  on  its  ability  to  provide  useful  ISR  to  operating  units.  A  basic 
employment  profile  for  the  operational  employment  of  a  hybrid-electric  RPA  concept  is 
depicted  in  figure  1 . 


For  example,  a  military  ground  unit,  with  intelligence  indicating  a  possible  increase  of 
insurgent  activity  in  a  nearby  township,  decides  to  evaluate  the  situation  before 
proceeding  with  intervening  actions.  In  this  situation,  high-value  low-density  assets 
(Satellite  imagery,  Global  Hawk,  or  Predator  RPA)  are  unavailable.  Gasoline/diesel 
powered  RPAs  are  noisy  and  may  tip-off  the  insurgents  that  they  are  being  observed  but 
the  quieter  electric  powered  RPAs  lack  the  range  necessary  to  both  ingress  and  egress  to- 
and-from  the  target  area  and  collect  ISR  data.  From  a  safe  undetectable  distance,  the 
hybrid-electric  RPA  could  be  quickly  setup  and  deployed,  flown  to  the  area  of  interest, 
loiter  and  collect  ISR  with  near-silent  operation,  regenerate  battery  capacity  if  prolonged 
near-silent  operation  is  required,  and  then  return  for  redeployment. 
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B.  Critical  Capabilities 

The  desired  mission  effects  can  only  be  realized  by  a  hybrid-electric  RPA  if  it  possesses 
the  following  critical  capabilities. 


Austere  Employment  Capability:  In  order  to  achieve  the  desired  effects,  the  hybrid- 
electric  RPA  must  be  deployable  in  numerous  terrains  and  environmental  conditions. 

The  hybrid-electric  RPA  system  will  be  transportable  in  a  one-vehicle/ATV  configuration 
and/or  towable  configuration.  It  may  be  further  broken  down  into  man-portable 
components.  System  design  has  been  optimized  for  minimal  fuel  (gasoline)  consumption. 
RPA  can  be  launched  and  recovered  with  minimal  clearance  restrictions.  A  portable 
catapult  launcher  further  enhances  potential  use  in  rugged  environments. 


Rapid  Ingress  and  Egress  Capability:  In  order  to  capture  timely  ISR  information  on 
potentially  fleeting  targets,  the  hybrid-electric  RPA  uses  a  multi-mode  internal 
combustion  engine  (ICE)  and  electric  motor  propulsion  system.  Propelling  the  HE -RPA 
solely  with  the  ICE  shall  provide  sufficient  speed  to  acquire  most  targets;  however, 
additional  speed  may  be  delivered  via  additive  power  of  the  electric  motor.  To  assure 
minimal  chance  of  detection,  the  same  mode  can  be  used  to  egress  from  the  target  area. 


Sustained  Near-Silent  Loiter  Capability:  The  primary  purpose  of  utilizing  RPAs  is  in 
the  collection  of  ISR  data.  In  order  to  successfully  fill  the  ISR  gap  that  exists  between 
low-density  high-value  assets,  gasoline/diesel  powered  RPAs,  and  electric  powered  RPS, 
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a  hybrid-electric  RPA  will  have  the  capability  to  loiter  over  a  target  area  for  a  sustained 
period  of  time  with  minimal  probability  of  detection  due  to  a  reduced  acoustic  signature. 


Effective  Multi-Mode  Operation:  The  hybrid-electric  RPA  possess  capabilities 
allowing  for  multi-mode  operation  facilitating  rapid  ingress/egress  and  sustained  near- 
silent  ISR  collection.  Primary  modes  of  operation  include  an  ingress/egress  (cruise) 
mode,  a  loiter  (endurance),  and  a  regeneration  (recharge)  mode.  The  HE-RPA  allows  for 
tailoring  of  mode  selection  criteria  in  order  to  meet  specific  mission  needs. 


Minimally  Complex  Operator  Interface:  An  essential  characteristic  of  the  hybrid- 
electric  RPA  is  focused  on  operation  and  control  with  minimal  operator  input.  Multiple 
aspects  of  the  operation  employment  scenarios  will  be  controlled  via  an  autonomous 
interface  with  manual  override  potential.  The  autonomous  control  strategies  and  initial 
design  aspects  of  the  hybrid-electric  RPA  will  be  implemented  as  specified  in  the 
system’s  architectural  design,  thereby  reducing  operator  interface  and  control  to 
essentially  point-and-click  control  via  the  ground  station. 


Adaptable  ISR  Payload  Capability:  The  hybrid-electric  RPA  will  accommodate 
different  ISR  payloads  with  a  configurable  bay.  Design  considerations  were  taken  to 
accommodate  the  electrical  and  structural  needs  of  a  multitude  of  sensors.  The  RPA  is 
well  suited  to  carrying  ISR  payloads  designed  for  low  altitude  employment. 


C.  Enabling  Capabilities 

In  order  to  support  he  critical  capabilities,  the  hybrid-electric  RPA  requires  a  small  set  of 
enabling  capabilities. 


Access  to  Global  Positioning  Satellite  Network:  The  hybrid-electric  RPA  relies  on  the 
global  positioning  satellite  (GPS)  for  waypoint  navigation.  The  hybrid-electric  RPA 
cannot  be  deployed  autonomously  in  areas  with  weak  or  denied  GPS  communication. 

Logistical  Support:  As  a  component  of  the  hybrid-electric  RPA,  the  internal  combustion 
engine  requires  a  small  amount  of  gasoline  for  sustained  operations.  The  ground  control 
station  also  requires  battery  power  or  generator  support  for  sustained  operations. 


Effective  Communication:  Operators  need  the  capability  to  relay  information  obtained 
with  the  hybrid-electric  RPA  to  commanders,  mission  planners,  or  additional  field  units. 
The  particular  method  is  left  to  the  operator’s  discretion. 

D.  Sequenced  Actions 
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A  hybrid-electric  RPA  system  will  be  considered  fully  operational  capable  when  a  unit  of 
operators  can  successfully  transport,  deploy,  control,  communicate,  collect  ISR  data, 
recover,  and  maintain  the  RPA  system. 


The  sequenced  actions  that  will  result  in  successful  operational  employment  of  a  hybrid- 
electric  RPA  are  shown  below.  The  sequenced  actions  are  segregated  into  anticipated 
mission  phases. 


Pre-deployment: 


•  Mission  Planning:  The  need  for  employment  and  intended  target  areas 
need  to  be  identified. 


•  Logistics  Planning:  Although  minimal,  the  necessary  logistics  support 
needs  to  be  pre-coordinated,  especially  for  extended-missions 


•  Sight  Selection:  Suitable  launch  and  recovery  locations  should  be 
identified  prior  to  launch.  Recovery  sight,  if  different  from  launch  sight, 
should  be  given  a  security  risk  evaluation. 


•  Communication:  Communication  between  operators  and  recipients  of 
collected  ISR  data  should  be  established  to  increase  mission 
effectiveness. 

Deployment: 

•  Transport:  Hybrid-electric  RPA  system  will  be  transported  to  launch 
sight.  Method  of  transport  will  be  dependent  on  specific  mission  scenario. 

•  Site  preparation:  Launch  site  should  be  evaluated  for  security  and  all 
potential  obstacles  should  be  removed 
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•  Inventory  and  Assembly:  Operators  will  ensure  all  necessary  RPA  and 
ground  station  components  are  present  before  launch.  The  RPA  system 
will  be  assembled  into  desired  configuration. 


•  Operation  Checkout:  Operations  will  perfonn  functional  checks  on  all 
equipment  prior  to  launch  in  order  to  ensure  safe  operation  and  that  RPA 
is  mission  capable.  Operator  will  also  establish  communication  between 
RPA  and  associated  units. 


•  Load  Mission  Profile:  Operator  will  upload  preliminary  mission  plan 
(waypoints)  as  dictated  per  mission  planning,  to  include  multi-mode 
operations. 


•  Vehicle  Launch:  RPA  launched  either  via  ground  rollout  or  catapult. 
Operation  will  consist  of  specific  modes  or  phases  as  indicated  below: 


o  Ingress/Cruise  -  RPA  utilizes  Internal  Combustion  Engine  (ICE)  to 
close  range  to  target  area 


o  Loiter/Endurance  -  RPA  utilizes  electric  motor  for  sustained  near- 
silent  ISR  data  collection 


■  Monitoring  and  Collection  of  ISR:  Operators  will 
monitor  ISR  feeds  and/or  data  collection.  Operators  will 
communicate  findings  to  necessary  personnel. 


■  Monitoring  of  RPA  Status:  Operators  will  monitor 
operational  parameters  of  vehicle  in  order  to  ensure  all 
systems  are  functioning  correctly  and  RPA  can  continue 
with  mission. 
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■  Update  Mission  Profile:  Mission  requirements  may 
change  throughout  duration  of  RPA  flight.  Operators  will 
update  mission  profile  via  communications  link  as  required. 


o  Recharge/Regenerate  -  RPA  utilizes  ICE  to  recharge  battery  stores 
for  additional  loiter/endurance  operation 


o  Egress/Cruise  -  RPA  utilizes  Internal  Combustion  Engine  (ICE)  to 
exit  target  area  and  traverse  to  recovery  location 

Recovery; 

•  Landing:  Upon  return  to  recovery  location,  RPA  will  self-initiate  a 
controlled  stall  landing  or  roll-out  landing;  specific  method  will  be 
selected  by  operator. 


•  Post-Flight:  Operator  will  inspect  vehicle  for  damage  and/or  reconfigure 
for  next  flight 


•  Disassembly  and  Packing:  Operator  will  disassembly  RPA  and  ground 
station  and  re-pack  into  transport  containers 


•  Inventory  and  Transport:  Operator  will  inventory  contents  of  transport 
containers  and  transport  RPA  to  next  location 


E.  End  State 

The  end  state  will  be  achieved  when  the  hybrid-electric  RPA  is  capable  of  providing  a 
sustained  near-silent  ISR  collection  capability  by  a  forward  deployed  unit  in  order  to 
meet  mission  requirements. 


Section  V  -  Summary 


The  benefits  of  utilizing  Remotely-Piloted  Aircraft  in  military  and  homeland  security 
operations  have  been  profound  over  the  last  decade.  However,  a  capability  gap  has 
developed  between  the  use  of  high-value  low-density  assets,  gas/diesel  powered  RPAs, 
and  electric  powered  RPAs.  The  hybrid-electric  RPA  possess  the  capabilities  needed  to 
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provide  ISR  coverage  when  high-value  low-density  assets  are  unavailable,  gas/diesel 
powered  RPAs  are  excessively  noisy,  and  electric  RPAs  lack  the  necessary 
range/endurance. 


This  CONOPS  details  an  employment  concept  for  the  utilization  of  a  hybrid-electric  RPA 
along  with  the  system’s  critical  capabilities,  the  required  enabling  capabilities,  and  a 
series  of  sequenced  actions  required  to  facilitate  mission  success.  Although  this 
CONOPS  details  a  generic  employment  concept  for  a  hybrid-electric  RPA,  the 
fundamental  organization  of  mission  elements  and  capabilities  should  be  applicable  to  all 
similar  system. 
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Appendix  B.  All  Viewpoint  1  (AV-1) 


Air  Force  Institute  of  Technology 
HEV  Architecture 

Overview  and  Summary  Infonnation  (AV-1) 
March  31,  201 1 


This  AV-1  is  an  executive-level  summary  of  the  Hybrid-Electric  UAV  architecture  as  a  portion  of 

an  Office  of  the  Secretary  of  Defense  (OSD)  funded  project  incoiporated  into  theses  for  the  Air 

Force  Institute  of  Technology.  This  initial  version  of  the  AV-1  focuses  the  architecture 

development  effort  by  documenting  the  scope  and  intended  usage. 

Architecture  Project  Identification 

Name 

Hybrid  Electric  Unmanned  Aerial  Vehicle  (HEV)  Architecture 

Architect 

Air  Force  Institute  of  Technology  (AF1T) 

Developed  By 

AF1T  Students:  Jacob  English,  Capt.  USAF;  Michael  Molesworth,  Capt. 

USAF 

Assumptions 

and 

Constraints 

The  HEV  architecture: 

•  Addresses  an  “as  intended’’  and  “as  built’’  HEV  configurations 

•  Follows  DoDAF  guidance 

•  Will  be  tailored  to  meet  strict  time  constraints  and  program  requirements 

•  Document  gaps  and  prescribe  mitigation  strategies 

Approval 

Authority 

Architecting  activities  will  be  approved  by  AF1T  faculty  advisors 

Date  Completed 

March  31,  2012 
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LOE  and  Costs 

Level  of  effort  will  be  consistent  with  similar  USAF  UAS  DT&E  initiatives. 

Efforts  will  be  tailored  according  to  the  prescribed  architecture  in  order  to 

meet  strict  time  constraints.  Funding  will  be  managed  by  AFIT  faculty  and 

limited  to  FY 1 0/FY 1 1  amounts. 

Products 

Developed 

HEV  architecture  consists  of  the  set  of  integrated  DoDAF  architecture 

products  -  AV-1,  OV-1,  OV-2,  OV-5,  SV-1,  SV-4,  SV-5,  SV-8,  SV-9,  and 

SV-10;  necessary  to  comply  with  DoDAF  requirements  and  to  distinguish 

between  the  “as  intended”  and  “as  implemented”  configurations 

Scope 

The  scope  of  the  HEV  architecture  is  to  identify  functions,  processes,  rules, 

data,  or  technology  that  is  required  in  order  to  successfully  develop  and 

demonstrate  the  “as  intended”  concept  and  to  identify  the  associated  gaps 

when  compared  to  the  “as  implemented”  configuration;  within  the  given  time 

and  budget  constraints. 

Time  Frames 
Addressed 

The  HEV  architecture  could  serve  as  the  basis  for  a  pre -developmental 

program  decision  process  in  order  to  support  a  desired  system  life-cycle 

beginning  in  FY  2012 

132 


Development  of  the  pre-acquisition  HEV  architecture  will  involve 
organizations  from  the  DoD  as  follows: 

•  Air  Combat  Command  (ACC)  and/or  Air  Force  Special  Operations 
Command  (AFSOC)  operational  functionals  for  system  requirement. 

•  Air  Force  Material  Command  (AFMC)  for  safety  requirements 

Organizations  «  Air  Force  Research  Fabs  (AFRF)  for  flight  authorization  and  test 

Involved 

plan  approval  requirements 

•  Air  Education  and  Training  Command  (AETC)  for  AF1T  MS 
program  requirements 

•  Financial  Management/  Comptroller  (to  be  implemented  by  AFIT 
cost  analysis  student) 


Purpose  and  Viewpoint 


The  HEV  architecture  will  provide  a  blueprint  for  vehicle  development,  gap  analysis, 
and  testing.  It  will  also  serve  as  a  guide  for  future  HEV  development  and/or 
verification  and  production  of  a  system  intended  to  provide  an  Enabling  Concept  for 
covert  ISR  operations  for  coalition  unmanned  air  systems  (UAS). 


Purpose  The  architecture  will  highlight  key  operational  parameters  valued  by  the  warfighter 

and  will  serve  as  a  guide  in  validating  performance  requirements.  It  will  serve  as  a 
reference  for  system  development,  verification,  and  employment. 


HEV  architecture  will  identify  the  capabilities  needed  to  produce  a  persistent  and 
covert,  UAS  based,  ISR  capability 
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The  following  questions  are  considered  critical  to  successful  completion  of  the 
architecting  effort.  The  HEV  architecture  should  be  capable  of  sufficiently  answering 
the  following: 

•  What  additional  efforts  are  needed  to  get  to  the  “as  intended”  configuration? 

•  What  are  the  technology  gaps? 

•  How  effective  will  it  be? 

•  How  will  effectiveness  be  tracked/measured? 

•  Will  it  provide  military  utility? 

•  Who  will  be  in  control  of  system? 

•  Does  current  doctrine  suffice  or  is  new  doctrine  needed? 

•  Is  it  easily  exploited  by  enemy? 

•  Who  are  the  users  and  stake  holders? 

•  Where  will  this  concept  be  used?  Where  will  it  be  used  successfully? 

The  HEV  architecture  is  developed  from  a  SySML  based  viewpoints  in 

support  of  DoDAF  V2.0. 


Context 


The  HEV  is  envisioned  as  an  essential  capability  multiplier  in  the  utilization 
of  military  1SR  via  the  use  of  unmanned  aerial  systems  (UAS)  to  extend  the 
realized  benefits  of  currently  employed  low-density  high-demand  1SR  assets. 

Mission 

An  integrated  system  will  be  critical  to  the  success  of  the  HEV.  Therefore, 
the  development  of  a  succinct  architecture  is  essential  and  considered  a 
critical  aspect  of  the  overall  mission  given  the  strict  time  constraints. 

•  Describe  a  methodology  for  efficient  and  complete  development  of  the  envisioned 
system  capable  of  fulfilling  the  HEV  requirements. 

Goals  .  Establish  techniques  for  rapid  but  thorough  concept  evaluation 

•  Support  DoD’s  decision  making  process  for  future  system  viability 

•  Provide  the  foundation  to  accelerate  system  development  and  implementation 
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Rules  - 


•  HEV  architectural  products  shall  be  developed  and  decomposed  only  to  the  level 
of  detail  required  to  adequately  fulfill  the  envisioned  CONOPS  and  answer  the 
critical  questions. 

Rules,  Criteria, 
and  Conventions 
Followed 

Criteria  and  Conventions  -  Guidance  contained  in  DoDAF  V2.0  and  AP233 
(SySML)  will  be  followed  to  the  greatest  extent  possible  in  order  to  facilitate 
future  reuse  of  products  and  data. 


Tools  and  File  Formats  Used 
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Appendix  C.  Textual  Use  Cases  and  Activity  Diagrams  (OV-5) 


Diagram:  Collect  ISR  Data 


act  Collect  ISR  Data_Activ  ityGraphWithActionPin 
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Diagram:  Communicate  with  Dispersed 
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Diagram:  Establish  Comm 
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Diagram:  Fly  in  Manual  Mode 
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Diagram:  Launch/Recover  Aircraft 
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Diagram:  Monitor  Aircraft  Status 
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Diagram:  Re-establish  Comm 


act  Re-establish  Comm_ActivityGraphWithActionPin 
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Diagram:  Relay  ISR  Data 


act  Relay  ISR  DataActivityGraphWit.. 


RPA 


Start 


End 
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Diagram:  Transfer  Control 


144 


Diagram:  Update  Aircraft  Flight  Profile 
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Appendix  D.  Systems  View  4  (SV-4)  System  Functionality  Description 


Function:  Communicate 


“As-intended” 


«SV-4»  obj  Systems  Functionality  Description  [Communication] 


/ 


“As-built” 


«SV-4»  obj  Systems  Functionality  Description  [Communication] 


«SystemFunction» 

Communicate 


«SystemFunction» 
Monitor  Communication 


«SystemFunction» 
Monitor  comm  with  RPA 


«SystemFunction» 
Monitor  Data  Link  Status 
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Function:  Provide  Electrical  Power 


“As-intended” 


«SV-4»  obj  Systems  Functionality  Description  [Provide  Electrical  Power] 

C  \ 

«SystemFunction» 
Provide  Electrical  Power 


V _ B _ J 

I 

i 

_ J _ 
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Function:  Provide  Persistent  ISR 


“As-intended’ 


“As-Built” 


«SV-4»  obj  Systems  Functionality  Description  [Provide  Persistent  ISR] 


«SystemFunction» 

-  Follow  moving  target 


«SystemFunction» 
-  ->>  Maintain  airframe 
integrity 


«SystemFunction» 
Provide  Persistant  ISR 


-> 


«SystemFunction» 
Track  flight  profile 


f  \ 

«SystemFunction» 
Maintain  contact  with 
target 

v _ y 


> 


«SystemFunction» 
Re-establish  broken 
data  links 


«SystemFunction» 
•^>  Adjust  flight  profile 


«SystemFunction» 

“  Transmit  ISR  to  users 


> 


«SystemFunction» 
Loiter  over  target 


«SystemFunction» 
Auto  connect 


«SystemFunction» 
Know  current  position 


«SystemFunction» 
Collect  ISR 


«SystemFunction» 
Minimize  fuel 
consumption 


«SystemFunction» 
^  Provide  continuous 
power  to  sensors 


\y 

r  > 

r 

«SystemFunctio... 

«SystemFunction» 

Communicate  with 

Process  GPS  Signa 

v  gcs  y 

V 

«SystemFunction» 
Identify  Targets 

v _ y 


\y 

«SystemFunction» 
l  Calculate  new  flight  path  J 


«SV-4»  obj  Systems  Functionality  Description  [Provide  Persistent 


ISR] 


«SystemFunction» 
Provide  Persistant  ISR 
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Function:  Rapid  Deployment  and  Recovery 


“As-intended” 


“As-Built” 


«SV-4»  obj  Systems  Functionality  Description  [Rapid  Deployment  and  Rec... 


«SV-4»  obj  Systems  Functionality  Description  [Rapid  Deployment  and  Rec... 

/  \ 

«SystemFunction» 

Rapid  Deployment  & 

Recovery 

v _ J 


r 

a 

r 

A 

«SystemFunction» 

«SystemFunction» 

> 

Rapid  airframe  assembly 

> 

Intuitive  construction 

V 

y 

V 

J 

L 


r 


-> 


\ 

«SystemFunction» 
Utilize  common  fuel 


v 


J 


-> 


«SystemFunction» 
Utilize  common  tools 
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Function:  Rapid  Ingress  &  Egress 


“As-Intended” 


«SV-4»  obj  Systems  Functionality  Description  [Rapid  Ingress  &Egress] 


y 


f  \ 

«SystemFunction» 
Rapid  Ingress/Egress 


\ _ , _ 

i 
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Function:  RPA  Control 


“As-Intended” 


«SV-4»  obj  Systems  Functionality  Description  [RPA  Control] 


«SystemFunction» 
Visually  Monitor  RPA 


«SystemFunction» 
Confirm  Transder  of 
Control 
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Appendix  F.  System  Evolution  Viewpoint  (SV-8) 


«SV-8»  tbl  Systems  Evolution  Description  [Systems  Evolution  Description] 


-  continued  on  next 
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System  Evolution  Viewpoint  (SV-8)  -  continued 


158 


Appendix  G.  Technology  Forecast  (SV-9) 


SV-9  Technology  & 
Skills  Forecast 

Time  Frame 

6  Months 

12  Months 

18  Months 

24+  Months 

Technology 

Batteries 

Solid  State  Lithium  Batteries  [7] 

Fuel  Cell  Based  batteries  [12] 

Electric  Motors 

Dual  Drive  Electric  Motors  [8] 

High-Efficiency,  High-Power-Density, 
Halbach  Array  Electric  Motor  [9] 

Controllers 

Robust  hybrid  electric  controller 

Integrated  autopilot  &  Hybrid 

controller 

Man-equivalent  reaction/process 
simulation  [7] 

Materials 

Resilient  Kevlar  &  Carbon  construction 

Vibration  absorbent  materials 

Shape  Memory  Alloys  [7] 

construction  [4] 

Reduced  Composite  8i  Optics  material 
weight  [7] 

Carbon  fiber  &  steel  truss  structure  [5] 

Construction  Methods 

Modular  Payloads  [3, 4] 

Modular/interchangeable  construction 

Industry  wide  airworthiness  standards 

[7] 

RPAs  designed  as  consumable  items  [7] 

ISO  9002/ISO  9001  and  IPC  standards 
[6] 

NATO  ISR  Interoperability  Standards  [7] 

Robust  &  Rapid  assembly  [3] 

Data  Links 

RPA/ground  relay  data  links 

Encrypted  2-9  GHzfrequencies 

Employment  of  Airborne 
Communication  Nodes  [ACN]  [7] 

Utilization  of  Wideband  Network 

Waveform  [7] 

Fuels 

Flexible  UAV  bladders  [11] 

Small  high  efficiency  fuel  injection  [13] 

Payloads 

Standardized  HDTV  formats  [7] 

Propellers 

Reduced  dB  performance 

Tunable/morphing  design 

Propeller  Optimization/Fluid  Dynamics 
Code  [xx] 

Prototyping 

Large  scale  Rapid  Prototyping  of 
aerospace  structures  [10] 

Rapid  ABS  Plastic  utilization 

Skills 

Personnel 

Unique  Air  Force  Specialty  Code  for  RPA 
Operators  [1] 

Training 

RPA  Fabrication  courses  [15] 

College  training  courses  [16] 

Dual  operational  &  training  systems  [7] 

Standardized  interfaces  [7] 

Training  courses  for  RPA  operators  8t 
Special  ForcesTeams  [1] 

Fabrication 

Utilization  of  Systems  Engineering 
Approaches [14] 

Requirements  for  standardized 
airframes  and  payloads  [1] 

Predicted 

Existing/Emerging 
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Appendix  H.  Throttle  Redirect  Code:  Procerus  Kestrel  Autopilot 


This  appendix  contains  a  sample  of  the  code  used  in  Virtual  Cockpit  to  implement 
propulsion  system  control  on  the  Kestrel  autopilot.  The  sample  code  shown  below  was 
generated  by  the  authors  and  integrated  into  an  existing  Procerus  Virtual  Cockpit 
GUI/add-in.  The  sample  code  shows  the  code  used  for  capturing  the  throttle  signal  from 
the  telemetry  downlink  stream.  In  addition,  the  code  shows  the  packet  intercept  to  divide 
the  throttle  between  the  ICE  and  EM  based  on  flight  mode.  Autopilot  signals  to  the  ICE 
and  EM  are  redirected  and  manipulated  from  the  pre-installed  gimbal  camera 
functionality  on  the  Kestrel  autopilot.  The  sample  code  shown  below  is  not  all-inclusive; 
questions  regarding  the  code  should  be  directed  towards  the  authors. 

Throttle  Capture  Code 

//Throttle 

unsigned  char  TempUChar; 
float  rawThrottle; 

memcpy (&TempUChar,  &NewPkt->PktData [39] ,1) ; 
rawThrottle  =  (TempUChar)  ; 

Mode  And  Throttle  Splitting  Code 

//Throttle  Command  sent  via  Gimbal  Command  Packet 

sVCPacket  GimbalPkt; 

CString  EditStr; 

GimbalPkt . VCPacketType  =  V C_G I MB AL_CMD ; 

GimbalPkt . DataSize  =  sizeof (sGimbalPacket) ; 

//Fill  up  the  data 
sGimbalPacket  GimbalCmd; 

GimbalCmd. DestAddr  =  m_UAVAddress; 

GimbalCmd. GimbalMode  =  0;  //GIMBAL  MODE  JOY  MSL 
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/////////////////////// 

//Mode  Selection  Code// 

/ / / / / / / III  III // / / III  III 

int  regen ; 

//Determine  Hybrid  Mode  Selection 

if ( ( (CButton* ) GetDlgltem (IDC_IDLE) ) ->GetCheck ( ) ) 

{ 

GimbalCmd. GimbalAzm  =  0.4f;  //set  idle  to  20%  throttle 
GimbalCmd. GimbalElev  =  O.Of;  //set  servo  position  to  off  in  radians 
regen  =  0; 

} 


else  if ( ( (CButton*) GetDlgltem (IDC_ICE) ) ->GetCheck ( ) ) 

{ 

GimbalCmd. GimbalAzm  =  rawThrottle/63 . 7f ;  //convert  throttle  signal  in  %  to 
radians  for  servo 

GimbalCmd. GimbalElev  =  O.Of;  //set  servo  position  to  off  in  radians; 
regen  =  0; 

} 


else  if ( ( (CButton* ) GetDlgltem (IDC_EM) ) ->GetCheck ( ) ) 

{ 

GimbalCmd. GimbalAzm  =  O.Of;  //set  servo  position  to  off  in  radians 

GimbalCmd. GimbalElev  =  (rawThrottle  *  0.9f)  /  63. 7f;  //convert  throttle  signal  (0- 
100%)  to  0-80%  to  limit  PWM  output  to  4V  instead  of  5V 

regen  =  0; 

} 


//Boost  Mode::ICE  driver.  Constant  EM// 

else  if ( ( (CButton* ) GetDlgltem (IDC_BOOST) ) ->GetCheck  ( ) ) 

{ 

GetDlgltem (IDC_IDEAL) ->GetWindowText (EditStr) ; 
float  IdealPower  =  (float) atof  (EditStr) ; 

GimbalCmd. GimbalElev  =  (IdealPower  *  0.90f)  /  63. 7f;  //Constant  EM-convert 
throttle  signal  in  %  to  radians  for  servo 

GimbalCmd. GimbalAzm  =  rawThrottle  /  63. 7f;  //convert  throttle  signal  in  %  to 
radians  for  servo 

//GimbalCmd. GimbalElev  =  0.785f;  //set  servo  position  to  50%  in  radian  for  EM 
regen  =  0; 

} 
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//Boost  Mode:: EM  driver.  Constant  ICE// 

else  if ( ( (CButton*) GetDlgltem ( IDC_B00ST2 ) ) ->GetCheck () ) 

{ 

GetDlgltem ( IDC_IDEAL) ->GetWindowText (EditStr ) ; 
float  IdealPower  =  (float) atof (EditStr)  ; 

GimbalCmd. GimbalAzm  =  IdealPower  /  63. 7f;  //Constant  ICE-convert  throttle  signal 
in  %  to  radians  for  servo 

//GimbalCmd. GimbalAzm  =  0.628f;  //set  servo  position  to  40%  in  radian  for  ICE 

GimbalCmd. GimbalElev  =  (rawThrottle  *  0.90f)  /  63. 7f;  //convert  throttle  signal 
(0-100%)  to  0-80%  to  limit  PWM  output  to  4V  instead  of  5V 

regen  =  0; 

} 


else  if ( ( (CButton*) GetDlgltem ( IDC_REGEN) ) ->GetCheck () ) 

{ 

GimbalCmd. GimbalAzm  =  (rawThrottle  /  63. 7f)  *  l.lf;  //Add  10%  to  throttle  signal 
GimbalCmd. GimbalElev  =  0.251f;  //set  servo  position  to  16%  in  radians 
regen  =  1; 

} 


else  //  Ensure  Idle  Mode  if  default  fails 

{ 

GimbalCmd. GimbalAzm  =  0.4f;  //set  idle  to  20%  throttle 
GimbalCmd. GimbalElev  =  O.Of;  //set  servo  position  to  off  in  radians 
regen  =  0; 

} 

GimbalCmd. TrgtLat  =  40. Of; 

GimbalCmd. TrgtLong  =  4 O.Of; 

GimbalCmd. TrgtElev  =  4 O.Of; 

//Now  that  we  have  our  structs  filled  copy  the  structs  to  the  VC  packet  that  will  be 

sent 

memcpy (GimbalPkt . PktData,  &GimbalCmd,  sizeof (sGimbalPacket) ) ; 

//Finally  send  the  packet 
m_VCConnector->SendData ( SGimbalPk 
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Appendix  I.  Bench,  Ground,  and  Flight  Test  Cards 


This  appendix  contains  all  of  the  test  cards  for  the  bench,  ground,  and  flight  testing.  The  cards  were  developed  by  the 
authors  and  edited  by  Ausserer  [12]  to  support  the  testing  plan  laid  out  in  Appendix  K.  Completed  test  cards  are  annotated  with 
the  test  data  reproduced  from  Ausserer  [12].  Notes  and  observations  from  during  the  test  are  also  included. 
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1.  BT-01:  CONDOR  HE  ICE  Only  Bench  Test  Card 

Completed:  31  January  2012,  Attempt  1 

Preconditions: 

Aircraft  secured  in  test  stand,  HE  system  passed  functional  check,  and  Autopilot  installation  and  ground  configuration  procedures  accomplished  as  described 
in  Section  1  through  Section  2.1  of  the  Procerus  Installation  and  Configuration  Guide  Document  Version  2.0,  dated  10/27/08.  Autopilot  mode  control  add-in 
verified  via  HE  functional  check.  Ensure  adequate  support  and  safety  measures  in  place. 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 


CONDOR  Configuration:  No  wings,  N/A-lbs,  18x10  2-blade  prop 

Objective: 

Verify  performance  of  integrated  HE  system  in  ICE  only  mode  under  manual  control 


BT-01:  PROCEDURES 

ICE  Throttle  Response 

1.  SO:  Ensure  fire  safety  and  test  stand  safety  measures  in  place 

2.  HEO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  “Manual  Mode” 

3.  HEO:  Record  starting  fuel  level 

4.  VCO:  Ensure  VC  and  VC  HE  add-in  loaded 

5.  HEO:  Power-up  and  initiate  HE  system 

6.  VCO:  Switch  to  RC  Mode 

7.  VCO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  “Manual  Mode 

8 .  VCO :  Set  VC  add-in  ICE  Only  Mode 

9.  VCO:  Set  ICE  throttle  to  50%  for  start-up 

10.  HEO:  Start  HE  system  &  Record  ICE  start  time 

1 1 .  HEO:  Verify  ICE  system  operating  correctly 


Notes: 


Duration:  30  min 


Starting  Fuel  Level:  1.825  kg 


ICE  Start  Time:12:13:03 

%  Throttle  for  Idle:22%,  3050  rpm 
Throttle  Position  (%):  30,  40,  50, 
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Notes: 


BT-01:  PROCEDURES 

12.  VCO:  Adjust  throttle  to  identify  idle  position;  restart  if  required 

13.  VCO:  Increase  throttle  10%  hold  30  sec 

14.  HEO:  Record  engine  speed 

15.  HEO/VCO:  Repeat  steps  13-14  until  100%  throttle;  stop  if  unacceptable  vibration 
develops 

16.  VCO:  Reduce  throttle  to  30%  to  simulate  cruise,  hold  20  min;  Record  starting  Fuel 
Level  &  end  fuel  level  for  test  point 

17.  VCO:  Reduce  throttle  to  0%,  Place  VC  into  SAFE  mode.  Record  ICE  Stop  time 

18.  HEO:  Ensure  HE  system  properly  shut  down 

19.  VCO/HEO/SP:  Proceed  to  Card  BT-02 


Duration:  30  min 


60,  70,  80 

Engine  Speed  (rpm):  3970,  4600,  5150, 


5290, 

5340,  5380 

ICE  Start  Time: 

12:19:30 

ICE  Stop  Time: 

12:39:30; 

Engine  Speed: 

4020  rpm 

Fuel  Level: 

Start:  1.780 

kg, 

End:  1.730 

kg 

Notes/Observations:  Test  accomplished  successfully 
on  first  attempt.  Aircraft  is  capable  of  ICE  only 
operation.  Solo  Whistle  maintained  commutation  and 
alignment  during  entire  test,  although  this  was  not  a  test 
objective. 
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2.  BT-02:  CONDOR  HE  EM  Only  Bench  Test  Card 

Completed:  1  February  2012,  Attempt  1 

Preconditions: 

Aircraft  secured  in  test  stand,  HE  system  passed  functional  check,  and  Autopilot  installation  and  ground  configuration  procedures  accomplished  as  described 
in  Section  1  through  Section  2.1  of  the  Procerus  Installation  and  Configuration  Guide  Document  Version  2.0,  dated  10/27/08.  Autopilot  mode  control  add-in 
verified  via  HE  functional  check.  Ensure  adequate  support  and  safety  measures  in  place. 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 


CONDOR  Configuration:  No  wings,  N/A-lbs,  18x10  2-blade  prop 

Objective: 

Verify  performance  of  integrated  HE  system  in  EM  only  mode  under  manual  control 


BT-02:  PROCEDURES 


EM  Throttle  Response 

1.  SO:  Ensure  fire  safety  and  test  stand  safety  measures  in  place 

2.  HEO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  “Manual  Mode” 

3.  VCO:  Ensure  VC  and  VC  HE  add-in  loaded 

4.  HEO:  Power-up  and  initiate  HE  system;  Start  EM  (commutate) 

5.  VCO:  Switch  to  Manual  Mode 

6.  VCO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  "Manual  Mode 

7.  VCO:  Set  VC  add-in  EM  Only  Mode 

8.  VCO:  Set  EM  throttle  to  0%  for  start-up 

9.  HEO:  Verify  HE  system  operating  correctly  (ICE  will  be  at  0%) 

10.  VCO:  Adjust  throttle  to  identify  min  EM  run  position  (EM  idle) 


Notes: 


%  Throttle  for  min  EM 
Throttle  Position  (%): 


run  position: 

21,  30, 


Dur:  30  min 


15% 

40, 
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Notes: 


BT-02:  PROCEDURES 

11.  VCO:  Increase  throttle  10%  hold  30  sec 

12.  HEO:  Record  battery  pack  voltage  &  current  draw  &  cumulative  power  &  motor 
speed 

13.  HEO/VCO:  Repeat  steps  13-14  until  100%  throttle 

14.  VCO:  Reduce  throttle  to  0%,  Place  VC  into  SAFE  mode 

15.  HEO:  Ensure  HE  system  properly  shut  down 

16.  VCO/HEO/SP:  Proceed  to  Card  BT-03 


Dur:  30  min 


50,  60, 

70, 

80, 

90, 

96 

Pack  Voltage  (V): 

32.9, 

32.9, 

32.9, 

32.8,  32.8 

32.3 

32.5, 

32.5, 

32.5, 

Current  Draw  (A): 

-0.6, 

0.0, 

0.74, 

1.8,  2.9, 

4.1, 

5.3, 

7.0, 

8.0 

Cumulative  Power  (mAhr): 

Initial: 

14 

16, 

19, 

23, 

33,  51, 

78, 

HI, 

157, 

202 

Motor  Speed  (rpm): 

1550, 

1630, 

2120, 

2490  2860, 

390 

3160, 

3420, 

3710, 

Notes/Observations:  Test  accomplished  successfully 
on  first  attempt.  Aircraft  is  capable  of  EM  only 
operation.  Operational  speeds  (rpm)  were  lower  than 
expected  based  on  simulation,  as  were  current  draws 
from  the  batteries.  This  is  more  likely  due  to  the 
performance  limits  of  the  Solo  Whistle  controller  than 
the  motor  or  batteries.  The  system  should  still  be 
capable  of  endurance  flight  based  on  power  draw  from 
the  batteries.  Pack  current  was  not  zeroed  at  the 
beginning  of  the  test.  There  is  a  -0.7  A  offset  in  the 
data. 
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3.  BT-03:  CONDOR  HE  ICE  to  EM  Bench  Test  Card 


Completed:  1  February  2012,  Attempt  2 


Preconditions: 

Aircraft  secured  in  test  stand,  HE  system  passed  functional  check,  and  Autopilot  installation  and  ground  configuration  procedures  accomplished  as  described 
in  Section  1  through  Section  2.1  of  the  Procerus  Installation  and  Configuration  Guide  Document  Version  2.0,  dated  10/27/08.  Autopilot  mode  control  add-in 
verified  via  HE  functional  check.  Ensure  adequate  support  and  safety  measures  in  place. 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 


CONDOR  Configuration:  No  wings,  N/A-lbs,  18x10  2-blade  prop 


Objective: 


Verify  HE  can  transition  from  ICE  mode  to  EM  mode  in  manual  control  and  then  operate  in  EM  mode 


BT-03:  PROCEDURES 


Notes: 


Dur:  30  min 


HE  Mode  Response 

1.  SO:  Ensure  fire  safety  and  test  stand  safety  measures  in  place 

2.  HEO:  Verify  VC  in  “Safe  Mode” 

3.  VCO:  Ensure  VC  and  VC  HE  add-in  loaded 

4.  HEO:  Power-up  and  initiate  HE  system;  commutate  EM 

5.  VCO:  Switch  to  Manual  Mode 

6.  VCO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  "Manual  Mode” 

7.  VCO:  Set  VC  add-in  ICE  Only  Mode 

8.  VCO:  Set  ICE  throttle  to  50%  for  start-up 

9.  HEO:  Start  HE  system 

10.  HEO:  Verify  HE  system  operating  correctly 

11.  VCO:  Adjust  throttle  to  10-20%  above  ICE  idle 

12.  VCO:  Set  VC  add-in  EM  Only  Mode 


EM  Response  Verification: 

(throttle  settings,  propeller  speed,  and  pack  current 


draw) 

ICE:  Idle; 

EM:  42%; 

3.6  A 

4350  rpm 

ICE:  Idle; 

EM:  35%; 

2.8  A 

4160  rpm 

ICE:  Idle; 

EM:  54%; 

5.0  A 

4700  rpm 
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Notes: 


Dur:  30  min 


HE  System  Operating  Correctly:  Yes 


EM  at  throttle:  Yes 


BT-03:  PROCEDURES 


13.  HEO:  Verify  EM  running  at  correct  throttle  setting 

14.  HEO:  Verify  ICE  reduced  to  idle 

15.  VCO/HEO/SP:  Proceed  to  Card  BT-04 


ICE  at  Idle:  Yes 

Notes/Observations:  EM  is  not  overrunning  ICE,  even 
with  ICE  at  idle  throttle. 

Attempt  1 :  During  the  first  attempt,  the  ICE  turned  off 
instead  of  going  to  idle  throttle.  The  coding  for  idle 
throttle  in  Virtual  Cockpit  had  been  set  to  0%  instead  of 
22%  as  determined  during  BT01.  After  correction, 
attempt  2  was  successful. 
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4.  BT-04:  CONDOR  HE  EM  to  ICE  Bench  Test  Card 


Completed:  1  February  2012,  Attempt  1 


Preconditions: 

Aircraft  secured  in  test  stand,  HE  system  passed  functional  check,  and  Autopilot  installation  and  ground  configuration  procedures  accomplished  as  described 
in  Section  1  through  Section  2.1  of  the  Procerus  Installation  and  Configuration  Guide  Document  Version  2.0,  dated  10/27/08.  Autopilot  mode  control  add-in 
verified  via  HE  functional  check.  Ensure  adequate  support  and  safety  measures  in  place. 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  No  wings,  N/A-lbs,  18x10  2-blade  prop 

Objective: 

Verify  HE  can  transition  from  EM  mode  to  ICE  mode  in  manual  control 


BT-04:  PROCEDURES 


Notes: 


HE  Mode  Response 

1.  SO:  Ensure  fire  safety  and  test  stand  safety  measures  in  place 

2.  HEO:  Verify  VC  in  “Safe  Mode” 

3.  VCO:  Ensure  VC  and  VC  HE  add-in  loaded 

4.  HEO:  Power-up  and  initiate  HE  system;  Commutate  EM 

5.  VCO:  Switch  to  Manual  Mode 

6.  VCO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  “Manual  Mode” 

7.  VCO:  Set  ICE  throttle  to  50%  for  start-up 

8.  HEO:  Start  HE  system 

9.  HEO:  Verify  HE  system  operating  correctly 

10.  VCO:  Set  VC  add-in  EM  Only  Mode,  adjust  throttle  (EM)  to  30%  to  ensure  control 

11.  HEO:  Verify  ICE  goes  to  idle 

12.  VCO:  Switch  to  ICE  only 


Throttle  controlling  EM:  Yes 
ICE  to  Idle:  Yes 


Dur:  30  min 
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BT-04:  PROCEDURES 

13.  HEO:  Verify  EM  off 

14.  HEO:  Verify  ICE  at  set  throttle 

15.  VCO/HEO/SP:  Proceed  to  Card  BT-05,  BT-06 


Notes: 


EM  turns  off:  Yes 
Throttle  controlling  ICE:  Yes 


Dur:  30  min 


Notes/Observations:  Throttle  verification  performed 
by  watching  for  a  change  in  propeller  speed  (rpm)  as 
throttle  was  adjusted  by  a  10%  step. 
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5.  BT-05,  BT-06:  CONDOR  HE  Dual  Mode  Bench  Test  Card 

Completed:  1  February  2012,  Attempt  1 

Preconditions: 

Aircraft  secured  in  test  stand,  HE  system  passed  functional  check,  and  Autopilot  installation  and  ground  configuration  procedures  accomplished  as  described 
in  Section  1  through  Section  2.1  of  the  Procerus  Installation  and  Configuration  Guide  Document  Version  2.0,  dated  10/27/08.  Autopilot  mode  control  add-in 
verified  via  HE  functional  check.  Ensure  adequate  support  and  safety  measures  in  place. 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 


CONDOR  Configuration:  No  wings,  N/A-lbs,  18x10  2-blade  prop 

Objective: 


Verify  HE  can  transition  to  dual  mode  (EM  driver  and  ICE  driver)  in  manual  control 

BT-05,  BT-06:  PROCEDURES 

Notes: 

Dur:  30  min 

EM  Driver  Test:  BT-05 

1. 

VCO:  Set  Dual  Mode  (ICE)  value  at  10-30% 

EM  Driver  Response  Verification: 

2. 

VCO:  Set  VC  add-in  to  Dual  Mode  (EM  Boost) 

(throttle  settings,  propeller  speed,  and  pack  current 

3. 

VCO:  Decrease  throttle  (EM)  to  0% 

draw) 

4. 

HEO:  Verify  EM  powers  down  &  ICE  remains  at  10-30%  setting 

Initial: 

5. 

VCO:  Increase  throttle  (EM)  to  30%  hold  30  sec 

ICE:  30%;  EM:  31%; 

4460  rpm 

6. 

HEO:  Verify  EM  powers  up 

3.6  A 

7. 

VCO:  Increase  throttle  (EM)  to  40% 

Adjust  Dual  Mode  throttle: 

8. 

HEO:  Verify  EM  powers  up 

ICE:  30%;  EM:  43%; 

4670  rpm 

9. 

VCO:  Change  ICE  set  point  to  40% 

4.0  A 

10. 

HEO:  Verify  ICE  powers  up 

Adjust  ICE  Set  point: 

ICE:  40%;  EM:  43%; 

5360  rpm 

ICE  Driver:  BT-06 

4.2  A 
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BT-05,  BT-06:  PROCEDURES 

11.  VCO:  Set  throttle  (EM)  at  50%,  ICE  set  point  at  30% 

12.  VCO:  Switch  to  ICE  driver 

13.  HEO:  Verify  EM  switches  to  30%  setting  &  ICE  powers  up  to  50% 

14.  VCO:  Decrease  throttle  (ICE)  to  20% 

15.  HEO:  Verify  ICE  powers  down 

16.  VCO:  Increase  throttle  (ICE)  to  30% 

17.  HEO:  Verify  ICE  powers  up 

18.  VCO:  Change  EM  set  point  to  40% 

19.  HEO:  Verify  EM  powers  up 

20.  HEO:  Return  to  ICE  only  mode 

21.  VCO/HEO/SP:  Proceed  to  Card  BT-07 
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Notes: 


Dur:  30  min 


ICE  Driver  Response  Verification: 

(throttle  settings,  propeller  speed,  and  pack  current 
draw) 

Initial: 

ICE:  19%;  EM:  30%;  3507  rpm 

1.9  A 

Adjust  Dual  Mode  throttle: 

ICE:  30%;  EM:  30%;  4500  rpm 

2.4  A 

Adjust  EM  Set  point: 

ICE:  40%;  EM:  50%;  4800  rpm 

5.2  A 

Notes/Observations:  The  EM  was  never  able  to 
overrun  the  ICE.  ICE  speed  increased  with  EM  throttle 
at  all  times.  Also,  above  50%  EM  throttle,  the  behavior 
of  the  ICE  servo  became  erratic.  Moving  the  ICE  servo 
wire  mitigated  the  behavior,  but  shielding  should  be 
included  for  the  signal  in  the  final  aircraft,  as  the  wire 
runs  alongside  the  EM  power  and  magneto. 


6.  BT-07:  CONDOR  HE  Emergency  Kill  Bench  Test  Card 

Completed:  1  February  2012,  Attempt  1 


Preconditions: 

Aircraft  secured  in  test  stand,  HE  system  passed  functional  check,  and  Autopilot  installation  and  ground  configuration  procedures  accomplished  as  described 
in  Section  1  through  Section  2.1  of  the  Procerus  Installation  and  Configuration  Guide  Document  Version  2.0,  dated  10/27/08.  Autopilot  mode  control  add-in 
verified  via  HE  functional  check.  Ensure  adequate  support  and  safety  measures  in  place. 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  No  wings,  N/A-lbs,  18x10  2-blade  prop 

Objective: 

Verify  HE  ICE  can  be  killed  in  emergency  situation  and  that  the  EM  still  functions 


BT-07:  PROCEDURES 

HE  System  Kill  Verification 

1.  HEO:  Ensure  system  started  &  EM  commutated 

2.  VCO:  Verify  system  is  in  ICE  mode 

3.  VCO:  Ensure  throttle  (ICE)  set  to  30% 

4.  HEO:  Activate  ICE  kill  switch 

5.  HEO:  Verify  ICE  stops  (EM  already  off) 

6.  VCO/HEO:  Restart  HE  system  in  ICE  only 

7.  VCO:  Set  Dual  Mode  (EM  Driver)  to  ICE  constant  value  40% 

8.  VCO:  Set  VC  add-in  to  Dual  Mode  (EM  Driver) 

9.  HEO:  Verify  EM  operating  at  30%  &  ICE  operating  at  40% 

10.  HEO:  Activate  ICE  kill  switch 

11.  HEO:  Verify  ICE  stops 

12.  VCO:  Increase  throttle  (EM)  to  60% 


Notes: 


Dur:  30  min 


Notes/Observations:  Despite  concerns  about  EM 
commutation  loss  during  an  ICE  shutdown,  EM 
functioned  flawlessly  with  no  loss  of  commutation. 
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BT-07:  PROCEDURES 

13.  HEO:  Verify  EM  powers  lip  &  functions  after  ICE  kill 

14.  VCO:  Set  throttle  to  0% 

15.  VCO:  Place  VC  in  Safe  Mode 

16.  HEO:  Power  down  HE  system 

17.  VCO/HEO/SP:  Proceed  to  Card  BT-08 


Notes: 


Dur:  30  min 
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7.  BT-08:  CONDOR  HE  Emergency  Kill  Bench  Test  Card 

Completed:  1  February  2012,  Attempt  1 


Preconditions: 

Aircraft  secured  in  test  stand,  HE  system  passed  functional  check,  and  Autopilot  installation  and  ground  configuration  procedures  accomplished  as  described 
in  Section  1  through  Section  2.1  of  the  Procerus  Installation  and  Configuration  Guide  Document  Version  2.0,  dated  10/27/08.  Autopilot  mode  control  add-in 
verified  via  HE  functional  check.  Ensure  adequate  support  and  safety  measures  in  place. 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  No  wings,  N/A-lbs,  18x10  2-blade  prop 

Objective: 

Verify  HE  EM  can  be  killed  in  emergency  situation 


BT-08:  PROCEDURES 

HE  System  EM  Kill  Verification 

1.  SO:  Ensure  fire  safety  and  test  stand  safety  measures  in  place 

2.  HEO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  “Manual  Mode” 

3.  VCO:  Ensure  VC  and  VC  HE  add-in  loaded 

4.  HEO:  Power-up  and  initiate  HE  system 

5.  VCO:  Switch  to  RC  Mode 

6.  VCO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  “Manual  Mode” 

7.  VCO:  Set  VC  add-in  ICE  Only  Mode 

8.  VCO:  Set  ICE  throttle  to  50%  for  start-up 

9.  HEO:  Start  HE  system 

10.  HEO:  Verify  HE  system  operating  correctly 

11.  VCO:  Adjust  throttle  to  ICE  idle  position 


Notes: 


Dur:  30  min 


Response  Verification: 

(throttle  settings,  propeller  speed) 


ICE:  30%; 

EM:  30%; 

4500  rpm 

ICE:  30%; 

EM:  Off; 

4000  rpm 

Notes/Observations:  No  issues  with  EM  shutdown. 
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Notes: 


BT-08:  PROCEDURES 

12.  VCO:  Set  Dual  Mode  (EM  Driver)  with  ICE  constant  value  at  30  % 

13.  VCO:  Set  VC  add-in  to  Dual  Mode  (EM  Boost) 

14.  HEO:  Verify  EM  throttle  control  &  ICE  operating  at  30% 

15.  HEO:  Set  throttle  (EM)  at  30% 

16.  HEO:  Activate  EM  kill  switch 

17.  HEO:  Verify  EM  stops 

18.  HEO:  Verify  ICE  remains  at  30% 

19.  VCO/HEO/SP:  Proceed  to  Card  BT-09 


Dur:  30  min 
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8.  BT-09:  CONDOR  HE  ICE  Crossover  Bench  Test  Card 

Completed:  3  February  2012,  Attempt  3 


Preconditions: 

Aircraft  secured  in  test  stand,  HE  system  passed  functional  check,  and  Autopilot  installation  and  ground  configuration  procedures  accomplished  as  described 
in  Section  1  through  Section  2.1  of  the  Procerus  Installation  and  Configuration  Guide  Document  Version  2.0,  dated  10/27/08.  Autopilot  mode  control  add-in 
verified  via  HE  functional  check.  Ensure  adequate  support  and  safety  measures  in  place. 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  No  wings,  N/A-lbs,  18x10  2-blade  prop 

Objective: 

Verify  HE  ICE  Crossover  functions  correctly 


BT-09:  PROCEDURES 


Notes: 


Dur:  30  min 


HE  System  ICE  Crossover  Verification 

1 .  VCO:  Set  VC  add-in  to  ICE  Mode 

2.  VCO:  Increase  throttle  (ICE)  to  40% 

3.  HEO:  Activate  ICE  Crossover  switch 

4.  VCO:  Switch  from  ICE  mode  to  EM  mode 

5.  VCO:  Vary  manual  throttle  10-30%  (Ice  should  respond  to  manual  control  in  EM  mode) 

6.  HEO:  Verify  ICE  positive  response 

7.  VCO:  Verify  HE  (ICE  control)  mode  control  inactive  &  control  through  Kestrel  AP 

8.  HEO:  Deactivate  Crossover  switch,  verify  ICE  control 

9.  VCO:  Switch  from  ICE  mode  to  EM  mode 


Notes/Observations:  No  issues  with  EM  shutdown. 

Attempt  1&2:  When  the  crossover  was  activated,  the 
engine  speed  increased  rapidly  and  the  belt  came  off  of 
the  EM  pulley.  There  exists  an  offset  between  the 
manual  and  autopilot  servo  ranges,  causing  the  rapid 
throttle  variation.  This  servo  range  was  correct  before 
attempt  3 . 
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Notes: 


BT-09:  PROCEDURES 

10.  VCO:  Vary  throttle  10-30% 

11.  HEO:  Verify  EM  positive  response 

12.  VCO:  Verify  HE  mode  control  active  &  control  through  Kestrel  AP  inactive 

13.  VCO/HEO/SP:  Proceed  to  Card  BT-10 


Dur:  30  min 
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9.  BT-10:  CONDOR  HE  Regen  Test  Card 

Completed:  1  February  2012,  Attempt  1 


Preconditions: 

Aircraft  secured  in  test  stand,  HE  system  passed  functional  check,  and  Autopilot  installation  and  ground  configuration  procedures  accomplished  as  described 
in  Section  1  through  Section  2.1  of  the  Procerus  Installation  and  Configuration  Guide  Document  Version  2.0,  dated  10/27/08.  Autopilot  mode  control  add-in 
verified  via  HE  functional  check.  Ensure  adequate  support  and  safety  measures  in  place. 


Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  No  wings,  N/A-lbs,  18x10  2-blade  prop 

Objective: 

Verify  HE  EM  ReGen  functions  correctly 


BT-10:  PROCEDURES 


Notes: 


Dur:  30  min 


HE  System  ReGen  Verification 

1.  HEO:  Record  battery  starting  battery  voltage,  ensure  at  least  2V  under  max 

2.  HEO:  Verify  EM  initially  off 

3.  VCO:  Set  VC  add-in  to  Regen  Mode,  Record  start  time 

4.  VCO:  Increase  throttle  (ICE)  to  30% 

5.  HEO:  Monitor  battery  pack  voltage,  record  time  for  voltage  to  increase  0.5V  (do  not 
start  with  fully  charged  battery  packs) 

6.  VCO:  Set  VC  add-in  to  ICE  Mode 

7.  VCO:  Decrease  throttle  to  20% 

8.  HEO:  Verify  ICE  throttle  response 

9.  VCO:  Set  VC  add-in  to  EM  Mode 


Starting  Battery  Voltage:  31.5  V 
Start  Time:  12:06:10 

End  Time:12:28:06 

End  Battery  Voltage:  32.0  V 

Total  power  (mAhr):  300 

Regen  Verification: 

(throttle  settings,  propeller  speed,  pack  current) 
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BT-10:  PROCEDURES 

10.  HEO:  Verify  ICE  goes  to  Idle 

11.  VCO:  Increase  throttle  to  40% 

12.  HEO:  Verify  EM  responds  to  throttle 

13.  VCO:  Decrease  throttle  to  0% 

14.  HEO:  Power  down  HE  system 

15.  VCO:  Power  Down  VC/Kestrel  AP 

16.  VCO/HEO/SP:  End  Test 
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Notes: 


Dur:  30  min 


ICE:  30%;  EM:  Off;  4130  rpm 

0  A 

ICE:  30%;  EM:  Regen;  4050  rpm 

1.15  A 

Notes/Observations:  Only  two  battery  packs  were  used 
during  the  Regeneration  test  for  safety  reasons. 


10.  GT-00:  CONDOR  HE  Kill  Mode  Verification  Test  Card 

Completed,  Qualitatively,  No  Telemetry  Data  (interference  issues),  15  February  2012 


Preconditions: 

Ground  Control  Station  (GCS)  set  up  and  proper  GCS  operation  verified.  Ensure  adequate  support  and  safety  measures  in  place. 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO). 
CONDOR  Configuration:  12-ft,  35  lbs,  18x10  2-blade  prop 

Objective: 

Verify  HE  system  kill  modes 


GT-00:  PROCEDURES 
Kill  mode  verification 

20.  SO:  Ensure  fire  safety  and  test  safety  measures  in  place 

21.  VCO:  Ensure  VC  in  Safe  Mode  prior  to  HE-RPA  startup 

22.  VCO:  Perform  Pre-engine  start-up  portion  of  Launch  Checklist 

23.  VCO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  “Manual  Mode 

24.  SO:  Ensure  RPA  is  restrained  &  personnel  have  PPE 


Notes: 


25.  HEO:  Conduct  HE-RPA  startup  checklist 

26.  VCO:  Set  VC  HE  add-in  to  ICE  only  mode 

27.  HEO:  Activate  ICE  kill  switch 

28.  HEO/VCO/SO:  Repeat  steps  3-6 

29.  VCO:  Set  VC  HE  add-in  to  EM  only  mode  (Ice  idle) 

30.  HEO:  Activate  EM  kill  switch 

31.  VCO:  Place  VC  in  Safe  Mode 

32.  SP/HEO/VCO:  Proceed  to  GT-01 


ICE  killed:  Yes /No 


EM  killed:  Yes /No 


Dur:  30  min 
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11.  GT-01:  CONDOR  HE  Takeoff  and  Dual  Mode  Ground  Test  Card 

Completed,  Qualitatively,  No  Telemetry  Data  (interference  issues),  15  February  2012 

Preconditions: 

Ground  Control  Station  (GCS)  set  up  and  proper  GCS  operation  verified.  Ensure  adequate  support  and  safety  measures  in  place. 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  No  Wings,  35  lbs,  18x10  2  blade  prop 

Objective: 

Verify  takeoff  (simulated)  &  performance  of  integrated  HE  system  in  dual  (ICE  Boost)  mode 


GT-01:  PROCEDURES 


Notes: 


Takeoff  &  Dual  Mode  (ICE  boost) 

1.  SO:  Ensure  fire  safety  and  test  safety  measures  in  place 

2.  VCO:  Ensure  CONDOR  PID  Values  uploaded  ,  &  waypoints  (WPAFB)  loaded  into  VC 

3.  VCO:  Ensure  VC  in  Safe  Mode  prior  to  HE-RPA  startup 

4.  HEO:  Record  starting  fuel  level  ofRPA 

5.  HEO:  Record  starting  battery  voltage  and  current  draw 

6.  VCO:  Perform  Pre-engine  start-up  portion  of  Launch  Checklist 

7.  VCO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  “Manual  Mode” 

8.  VCO:  Place  VC  HE  add-in  to  ICE  Only 


Starting 

Starting 

Starting 


Fuel  Level: _ 

battery  voltage: 
Current  Draw: 


Dur:  30  min 
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GT-01:  PROCEDURES 


Notes: 


Dur:  30  min 


9.  HEO:  Conduct  HE-RPA  startup  checklist,  record  ICE  start  time 

10.  SP:  Adjust  ICE  throttle  to  idle 

11.  VCO:  Set  VC  HE  add-in  to  Dual  Mode  (ICE  Boost),  set  EM  constant  to  30% 

12.  VCO:  Adjust  EM  constant  to  lower  value  if  needed  to  prevent  taxi 

13.  SP:  Increase  ICE  throttle  until  RPA  begins  to  taxi 

14.  SP:  Accelerate  RPA  to  simulate  takeoff 

15.  SP:  Record  throttle  position  for  estimated  takeoff  speed  (if  not  100%) 

16.  VCO:  Record  throttle  position,  estimated  speed,  and  engine  speed 

17.  SP:  Reduce  throttle,  rotate  RPA  180deg  and  repeat  in  opposite  direction 

18.  SP:  Determine  if  EM  throttle  constant  needs  to  be  adjusted  up  or  down 

19.  VCO:  Adjust  EM  throttle  constant  as  necessary  for  proceeding  trial 

20.  SP/VCO/HEO:  Repeat  steps  10-15  until  SP  identifies  preferred  throttle  combination 

21.  VCO:  Place  RPA  in  IDLE  Mode 

22.  VCO/HEO/SP:  Proceed  to  Card  GT-02 


ICE  Start  Time: _ 

Min  EM  Throttle  Constant: 

%  Throttle: _ , _ , _ ,  _ 

Estimated  Takeoff  speed: _ 

Propeller  Speed: _ , _ ,  _ 

Current  Draw: _ , _ , _ 

EM  Throttle  Constant: _ , 
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12.  GT-02:  CONDOR  HE  ICE  Mode  Test  Card 

Completed,  Qualitatively,  No  Telemetry  Data  (interference  issues),  15  February  2012 

Preconditions: 

Completion  of  Test  Card  GT-01,  Ground  Control  Station  (GCS)  set  up  and  proper  GCS  operation  verified.  Ensure  adequate  support  and  safety  measures  in 
place. 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  12-ft,  35  lbs,  18x10  2-blade  prop 

Objective: 

Verify  correct  operation  of  HE  RPA  ICE  mode  &  mode  switching 


GT-02:  PROCEDURES 


Notes: 


ICE  Only  Mode  Checkout 

1 .  VCO:  Set  VC  HE  add-in  to  ICE  only  mode 

2.  SP/HEO:  Verify  EM  off  &  ICE  responds  to  manual  throttle  commands 

3.  SP:  Increase  throttle  until  RPA  begins  to  taxi 

4.  VCO:  Record  min  taxi  throttle  setting,  min  taxi  speed,  and  engine  speed 

5.  SP:  Taxi  RPA  for  4  laps,  operator  choice  of  throttle 

6.  VCO:  Place  RPA  in  Idle 

7.  VCO/HEO/SP:  Proceed  to  Card  GT-03 


%  Throttle  for  taxi: 

Min  taxi  speed: _ 

Min  Engine  Speed:_ 

Taxi  throttle: _ 

Taxi  Prop  Speed: _ 


Dur:  30  min 
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13.  GT-03:  CONDOR  HE  EM  Mode  Test  Card 

Completed,  Qualitatively,  No  Telemetry  Data  (interference  issues),  15  February  2012 


Preconditions: 

Completion  of  Test  Card  GT-02,  Ground  Control  Station  (GCS)  set  up  and  proper  GCS  operation  verified.  Ensure  adequate  support  and  safety  measures  in 
place. 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  12-ft,  35  lbs,  18x10  2-blade  prop 

Objective: 

Verify  correct  operation  of  HE-RPA  EM  mode  &  mode  switching 


GT-03:  PROCEDURES 


Notes: 


EM  Only  Mode  Checkout 

1 .  VCO:  Set  VC  HE  add-in  to  EM  only  mode 

2.  SP/HEO:  Verify  EM  responds  to  manual  throttle  commands  &  ICE  goes  to  idle 

3.  SP:  Increase  throttle  until  RPA  begins  to  taxi 

4.  VCO:  Record  min  taxi  throttle  setting,  min  taxi  speed,  and  engine  speed 

5.  SP:  Taxi  RPA  for  4  laps,  operator  choice  of  throttle 

6.  VCO:  Place  RPA  in  Idle 

7.  VCO/HEO/SP:  Proceed  to  Card  GT-04 


%  Throttle  for  taxi: 

Min  taxi  speed: _ 

Min  Engine  Speed:_ 
Min  current  draw:_ 

Taxi  throttle: _ 

Taxi  Prop  Speed: _ 

Current  draw: _ 


Dur:  30  min 
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GT-04:  CONDOR  HE  ICE  Mode  Test  Card 

Completed,  Qualitatively,  No  Telemetry  Data  (interference  issues),  15  February  2012 

Preconditions: 

Completion  of  Test  Card  GT-01,  Ground  Control  Station  (GCS)  set  up  and  proper  GCS  operation  verified.  Ensure  adequate  support  and  safety  measures  in 
place. 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  12-ft,  35  lbs,  18x10  2-blade  prop 

Objective: 

Verify  correct  operation  of  HE-RPA  Dual  mode  &  mode  switching 


GT-04:  PROCEDURES 


Notes: 


Dual  Mode  (EM  Boost)  Checkout 

1.  VCO:  Set  VC  HE  add-in  throttle  constant  to  40%  (ICE  will  be  40%)**  Reduce  if  needed 

2.  VCO:  Set  VC  HE  add-in  to  Dual  mode  (EM  boost)  mode 

3.  SP/HEO:  Verify  EM  responds  to  manual  throttle  commands  &  ICE  goes  to  40% 

4.  SP:  Increase  throttle  until  RPA  begins  to  taxi 

5.  VCO:  Record  min  taxi  throttle  setting,  min  taxi  speed,  and  engine  speed 

6.  SP:  Adjust  throttle  until  controllable  taxi  achieved 

7.  SP:  Taxi  RPA  for  4  laps 

8.  VCO:  Place  RPA  in  Idle 


%  Throttle  (ICE)  for  min  taxi: 

Min  taxi  speed: _ 

Min  Engine  Speed: _ 

Current  Draw: _ 

%  Throttle  for  taxi: _ 

Taxi  speed: _ 

Taxi  Engine  Speed: _ 


Dur:  30  min 
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GT-04:  PROCEDURES 

Dual  Mode  (ICE  Boost)  Checkout 

9.  VCO:  Set  VC  HE  add-in  throttle  constant  to  40%  (EM  will  be  40%)**  Reduce  if  needed 

10.  VCO:  Set  VC  HE  add-in  to  Dual  mode  (ICE  boost)  mode 

11.  SP/HEO:  Verify  ICE  responds  to  manual  throttle  commands  &  EM  goes  to  40% 

12.  SP:  Increase  throttle  until  RPA  begins  to  taxi 

13.  VCO:  Record  min  taxi  throttle  setting,  min  taxi  speed,  and  engine  speed 

14.  SP:  Adjust  throttle  until  controllable  taxi  achieved 

15.  SP:  Taxi  RPA  for  4  laps 

16.  VCO:  Place  RPA  in  Idle 

17.  SP/HEO:  Kill  RPA  ICE 

18.  HEO:  Record  engine  stop  time  and  ending  fuel  state 

19.  VCO/HEO/SP:  Proceed  to  Card  GT-05 


Notes: 


Current  Draw: 


%  Throttle  (EM)  for  min  taxi: 

Min  taxi  speed: _ 

Min  Engine  Speed: _ 

Current  Draw: _ 

%  Throttle  for  taxi: _ 

Taxi  speed: _ 

Taxi  Engine  Speed: _ 

Current  Draw: _ 


Dur:  30  min 


Engine  stop  time: 
Final  Fuel  State: 
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FT-05:  CONDOR  HE  ICE  Crossover  &  Cruise  Test  Card 

Completed,  Qualitatively,  No  Telemetry  Data  (interference  issues),  15  February  2012 

Preconditions: 

Completion  of  GT-04 


Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  12-ft,  35  lbs,  18x10  2-blade  prop 
Objective: 

Verify  HE  can  transition  manual  control  to  autopilot  and  evaluate  cruise  performance 


FT-05:  PROCEDURES 


Notes: 


HE  System  ICE  Crossover  Verification 

1.  SO:  Ensure  fire  safety  and  test  safety  measures  in  place 

2.  VCO:  Ensure  CONDOR  PID  Values  uploaded  ,  and  waypoints  loaded  into  VC  (vary 
speeds  for  ground  testing) 

3.  VCO:  Ensure  VC  in  Safe  Mode  prior  to  HE-RPA  startup 

4.  HEO:  Record  starting  fuel  level  ofRPA 

5.  VCO:  Perform  Pre-engine  start-up  portion  of  Launch  Checklist 

6.  VCO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  “Manual  Mode” 

7.  VCO:  Place  VC  HE  add-in  to  ICE  only 

8.  HEO:  Conduct  HE-RPA  startup  checklist,  record  ICE  start  time 

9.  VCO:  Set  VC  HE  add-in  to  Dual  Mode  (ICE  Boost),  EM  throttle  constant  (-30%) 

10.  SP:  Accelerate  RPA  to  approximated  cruise  speed  (or  appropriate  for  safe  ground  ops) 


Starting  Fuel  Level: 


ICE  Start  Time: 


Dur:  30  min 
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FT-05:  PROCEDURES 

11.  SP:  Begin  test  laps  with  RPA 

12.  VCO:  Reduce  EM  throttle  constant  if  directed  by  SP 

13.  VCO:  Record  trim  throttle  position,  trim  airspeed,  and  engine  speed 

14.  HEO:  Activate  Crossover  switch 

15.  SP/VCO:  Verify  autopilot  has  control  of  aircraft  (Ice  should  respond  to  manual  control 
in  EM  mode) 

16.  HEO:  Deactivate  Crossover  switch 

17.  SP/VCO:  RPA  in  back  in  manual  control  (back  to  Dual  Mode) 

18.  VCO:  Switch  to  ICE  only  mode  (now  in  manual  ICE  mode) 

19.  HEO:  Verify  EM  off 

20.  HEO:  Activate  crossover  switch 

21.  SP/VCO:  Verify  autopilot  has  control  of  aircraft 

22.  HEO:  Deactivate  Crossover  switch  (Back  to  manual  ICE) 

23.  SP/VCO:  Monitor  RPA  under  manual  control  for  10+  min  grnd  test,  set  to  cruise 
velocity 

24.  SP:  Recover  RPA 

25.  VCO:  Place  VC  in  Safe  Mode 

26.  HEO:  Record  engine  stop  time  and  ending  fuel  state 

27.  VCO/HEO/SP:  Proceed  to  Card  GT-06 


Notes: 


Speed: _ 

%  Throttle: _ 

Engine  Speed: 


Engine  stop  time: 
Final  Fuel  State: 


Dur:  30  min 
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14.  GT-07:  CONDOR  HE  ReGen  Mode  &  Kill  Switch  Test  Card 


Kill  Tests  Completed,  Qualitatively,  No  Telemetry  Data  (interference  issues),  15  February  2012 
Regen  not  attempted  due  to  interference  issues  during  testing, 

Preconditions: 

Completion  of  GT-06 


Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  12-ft,  35  lbs,  18x10  2-blade  prop 
Objective: 

Verify  HE  EM  ReGen  and  ICE  Kill  switch  function  correctly 


GT-07:  PROCEDURES 


Notes: 


HE  System  ReGen  Verification 

1.  SO:  Ensure  fire  safety  and  test  safety  measures  in  place 

2.  VCO:  Ensure  CONDOR  PID  Values  uploaded  ,  and  waypoints  loaded  into  VC 

3.  VCO:  Ensure  VC  in  Safe  Mode  prior  to  HE-RPA  startup 

4.  HEO:  Record  battery  starting  battery  voltage  &  current,  ensure  at  least  2V  under  max 

5.  HEO:  Record  starting  fuel  level  of  RPA 

6.  VCO:  Perform  Pre-engine  start-up  portion  of  Launch  Checklist 

7.  VCO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  “Manual  Mode” 

8.  VCO:  Place  VC  HE  add-in  to  ICE  Only 

9.  HEO:  Conduct  HE-RPA  startup  checklist,  record  ICE  start  time 

10.  VCO:  Set  VC  HE  add-in  to  Dual  Mode  (ICE  Boost),  EM  throttle  constant  (-30%) 


Starting  Battery  Voltage: 
Current: _ 

Starting  Fuel  Level: _ 


Start  Engine  Start  Time: 


Dur:  30  min 


Starting 


192 


GT-07:  PROCEDURES 


11.  SP:  Accelerate  RPA  to  approximated  cruise  speed  (or  appropriate  for  safe  grnd  ops) 

12.  SP:  Begin  test  laps  with  RPA 

13.  VCO:  Reduce  EM  throttle  constant  is  directed  by  SP 

14.  VCO:  Record  trim  throttle  position,  trim  airspeed,  and  engine  speed 

15.  VCO:  Set  VC  add-in  to  ICE  only  Mode 

16.  HEO:  Verify  EM  off 

17.  HEO:  Record  Battery  pack  voltage  &  ReGen  start  time 

18.  VCO:  Set  VC  add-in  to  Regen  Mode 

19.  HEO:  Maneuver  RPA  in  lap  pattern  &  monitor  battery  pack  voltage,  record  time  for 
voltage  to  increase  0.5V 

20.  VCO:  Place  VC  HE  add-in  to  ICE  Only 

**Simulated  -  HIGH  RISK** 

ICE  Kill  for  Silent  Operation 

21.  VCO:  Set  VC  add-in  to  EM  Mode 

22.  HEO:  Verify  EM  powers  up  &  ICE  goes  to  idle 

23.  SP:  Verify  EM  throttle  response,  prepare  for  simulated  emergency  landing 

24.  HEO:  Activate  ICE  Kill  Switch 

25.  HEO:  Verify  ICE  killed  &  Record  engine  stop  time 

26.  SP:  Verify  RPA  performance  under  EM  only  mode  (no  ICE) 

EM  Kill  verification 

27.  HEO:  Activate  EM  kill  switch  just  prior  to  touchdown 
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Notes: 


Dur:  30  min 


Starting  Battery  Voltage: 
Start  ReGen  Time: _ 

Pack  Current: _ 

Ending  Battery  Voltage:_ 
End  ReGen  Time: _ 


GT-07:  PROCEDURES 

28.  SP:  Recover  **Simulated  Dead  stick  Landing”” 

29.  VCO:  Place  VC  in  Safe  Mode 

30.  HEO:  Record  final  fuel  state 

31.  VCO/HEO/SP:  End  Testing 


194 


Notes: 


Dur:  30  min 


Engine  stop  time: 


Final  Fuel  State: 


15.  FT-OO:  CONDOR  HE  Kill  Mode  Verification  Test  Card 


Preconditions: 

Ground  Control  Station  (GCS)  set  up  and  proper  GCS  operation  verified.  Ensure  adequate  support  and  safety  measures  in  place. 
Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO). 

CONDOR  Configuration:  12-ft, _ -lbs,  18x10  2-blade  prop 

Objective: 

Verify  HE  system  kill  modes 


FT-00:  PROCEDURES  Notes:  Dur:  30  min 


Kill  mode  verification 

1.  SO:  Ensure  fire  safety  and  test  safety  measures  in  place 

2.  VCO:  Ensure  VC  in  Safe  Mode  prior  to  HE-RPA  startup 

3.  VCO:  Perform  Pre-engine  start-up  portion  of  Launch  Checklist 

4.  VCO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  “Manual  Mode” 

5.  SO:  Ensure  RPA  is  restrained  &  personnel  have  PPE 

6.  HEO:  Conduct  HE-RPA  startup  checklist 

7.  VCO:  Set  VC  HE  add-in  to  ICE  only  mode 

8.  HEO:  Activate  ICE  kill  switch  ICE  killed:  Yes /No 

9.  HEO/VCO/SO:  Repeat  steps  3-6 
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FT-OO:  PROCEDURES 

10.  VCO:  Set  VC  HE  add-in  to  EM  only  mode  (ICE  idle) 

11.  HEO:  Activate  EM  kill  switch 

12.  VCO:  Place  VC  in  Safe  Mode 

13.  SP/HEO/VCO:  Proceed  to  FT-01 
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Notes: 


Dur:  30  min 


EM  killed:  Yes /No 


16.  FT-01:  CONDOR  HE  Dual  Mode  (ICE  Boost)  Flight  Test  Card 


Preconditions: 

Aircraft  secured  in  test  stand,  HE  system  passed  functional  check,  and  Autopilot  installation  and  ground  configuration  procedures  accomplished  as  described 
in  Section  1  through  Section  2.1  of  the  Procerus  Installation  and  Configuration  Guide  Document  Version  2.0,  dated  10/27/08.  Autopilot  mode  control  add-in 
verified  via  HE  functional  check.  Ensure  adequate  support  and  safety  measures  in  place. 


Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 


CONDOR  Configuration:  12-ft, _ -lbs,  18x10  2-blade  prop 


Objective: 

Verify  takeoff  &  flight  performance  of  integrated  HE  system  in  dual  (ICE  Boost)  mode 


FT-01:  PROCEDURES 


Notes: 


Takeoff  &  Dual  Mode  (ICE  boost) 

1.  SO:  Ensure  fire  safety  and  test  safety  measures  in  place 

2.  VCO:  Ensure  CONDOR  PID  Values  uploaded  ,  and  waypoints/rally  points  loaded  into 
VC 

3.  VCO:  Ensure  VC  in  Safe  Mode  prior  to  HE-RPA  startup 

4.  HEO:  Record  starting  fuel  level  ofRPA 

5.  HEO:  Record  starting  battery  voltage  and  current  draw 

6.  VCO:  Perform  Pre-engine  start-up  portion  of  Launch  Checklist 

7.  VCO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  “Manual  Mode” 


Starting  Fuel  Level: 


Starting  battery  voltage: 
Draw: _ 


Dur:  30  min 


Starting  Current 
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FT-01:  PROCEDURES 

8.  HEO:  Conduct  HE-RPA  startup  checklist,  record  ICE  start  time 

9.  VCO:  Set  VC  HE  add-in  to  Dual  Mode  (ICE  Boost) 

10.  SP:  Launch  aircraft 

11.  SP:  Trim  the  CONDOR  for  level  flight  at  700  ft 

12.  VCO:  Record  trim  throttle  position,  trim  airspeed,  and  engine  speed 

13.  SP:  Fly  minimum  4  laps  around  airfield 

14.  VCO/HEO/SP:  Proceed  to  Card  FT-02 
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Notes: 


Dur:  30  min 


ICE  Start  Time: 

Trim  Airspeed:_ 
%  Throttle  trim: 
Engine  Speed: _ 


17.  FT-02:  CONDOR  HE  ICE  Mode  Flight  Test  Card 


Preconditions: 

Completion  of  FT-01,  RPA  in  trimmed  &  stable  flight,  in  Dual  Mode  (ICE  Boost) 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  12-ft, _ -lbs,  18x10  2-blade  prop 

Objective: 

Verify  performance  of  integrated  HE  system  in  ICE  only  mode 


FT-02: 

PROCEDURES 

Notes: 

Dur:  30  min 

ICE  Mode  Checkout  (ICE  Boost  -  ICE  Only  -  EM  Only) 

1. 

SP/VCO:  Verify  RPA  trimmed  at  700  ft  and  in  dual  mode 

2. 

VCO:  Set  VC  HE  add-in  mode  to  ICE  only 

3. 

SP:  Recover  RPA  to  700ft  and  trimmed  flight  if  needed 

4. 

HEO:  Verify  EM  off 

5. 

VCO:  Record  trim  throttle  position,  trim  airsDeed.  and  engine  speed 

Trim  Airspeed: 

6. 

SP:  Complete  4  laps  around  airfield 

%  Throttle  trim: 

7. 

VCO:  Set  VC  HE  add-in  mode  to  EM  Only 

Engine  Speed: 

8. 

HEO:  Verify  ICE  goes  to  idle 

9. 

VCO/HEO/SP:  Proceed  to  Card  FT-03 
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18.  FT-03:  CONDOR  HE  EM  Mode  Flight  Test  Card 


Preconditions: 

Completion  of  FT-02,  RPA  in  trimmed  &  stable  flight,  in  EM  Mode 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  12-ft, _ -lbs,  18x12  2-blade  prop 

Objective: 

Verify  performance  of  integrated  HE  system  in  EM  only  mode 


FT-03:  PROCEDURES 

EM  Mode  Checkout  (EM  Only  -  ICE  Only) 

1.  SP/VCO:  Verify  RPA  trimmed  at  700  ft  and  in  EM  Only  mode 

2.  VCO:  Set  VC  HE  add-in  mode  to  ICE  Only 

3.  SP:  Recover  RPA  to  700ft  and  trimmed  flight  if  needed 

4.  HEO:  Verify  EM  off 

5.  VCO:  Record  trim  throttle  position,  trim  airspeed,  and  engine  speed 

6.  SP:  Complete  4  laps  around  airfield 

7.  VCO/HEO/SP:  Proceed  to  Card  FT-04 


Notes: 


Trim  Airspeed:_ 
%  Throttle  trim: 
Engine  Speed: _ 


Dur:  30  min 
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19.  FT-04:  CONDOR  HE  Dual  Mode  Flight  Test  Card 


Preconditions: 

Completion  of  FT-03,  RPA  in  trimmed  &  stable  flight,  in  ICE  Mode 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  12-ft, _ -lbs,  18x10  2-blade  prop 

Objective: 

Verify  performance  of  integrated  HE  system  in  Dual  mode 


FT-04:  PROCEDURES 

Dual  Mode  Checkout  (ICE  -  EM  Boost) 

1.  SP/VCO:  Verify  RPA  trimmed  at  700  ft  and  in  ICE  mode 

2.  VCO:  Set  Dual  mode  throttle  constant  to  10%  above  ICE  idle  (~  40%) 

3.  VCO:  Set  VC  HE  add-in  mode  to  Dual  mode  (EM  Boost) 

4.  SP:  Verify  EM  throttle  control.  Recover  RPA  to  700ft  and  trimmed  flight  if  needed 

5.  HEO:  Verify  ICE  at  constant  setting  (-40%)  -  step  2 

6.  VCO:  Record  trim  throttle  position,  trim  airspeed,  and  engine  speed 

7.  SP:  Complete  4  laps  around  airfield 

8.  SP:  Conduct  landing  approach  to  determine  necessary  throttle  settings 

9.  VCO:  Reduce  Dual  mode  throttle  constant  if  directed  by  SP 

10.  SP:  Recover/Land  RPA 

1 1 .  HEO:  Record  engine  stop  time  and  ending  fuel  state 

12.  VCO/HEO/SP:  Proceed  to  Card  FT-05 


Notes: 


Trim  Airspeed:_ 
%  Throttle  trim: 
Engine  Speed: _ 


Engine  stop  time: 
Final  Fuel  State: 


Dur:  30  min 
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FT-05:  CONDOR  HE  ICE  Crossover  &  Cruise  Test  Card 


Preconditions: 

Completion  of  FT-04 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  12-ft, _ -lbs,  18x10  2-blade  prop 

Objective: 

Verify  HE  can  transition  manual  control  to  autopilot  and  evaluate  cruise  performance 


FT-05:  PROCEDURES 


Notes: 


HE  System  ICE  Crossover  Verification 

1.  SO:  Ensure  fire  safety  and  test  safety  measures  in  place 

2.  VCO:  Ensure  CONDOR  PID  Values  uploaded  ,  and  waypoints/rally  points  loaded  into 
VC 

3.  VCO:  Ensure  VC  in  Safe  Mode  prior  to  HE-RPA  startup 

4.  HEO:  Record  starting  fuel  level  ofRPA 

5.  HEO:  Record  starting  battery  voltage  and  current  draw 

6.  VCO:  Perform  Pre-engine  start-up  portion  of  Launch  Checklist 

7.  VCO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  “Manual  Mode” 

8.  HEO:  Conduct  HE-RPA  startup  checklist,  record  ICE  start  time 


Starting  Fuel  Level: _ 

Starting  battery  voltage: 
Draw: _ 


Dur:  30  min 


Starting  Current 
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FT-05:  PROCEDURES 


Notes: 


Dur:  30  min 


9.  VCO:  Set  VC  HE  add-in  to  Dual  Mode  (ICE  Boost),  EM  throttle  constant  (-40%) 

10.  SP:  Launch  aircraft 

11.  SP:  Trim  the  CONDOR  for  level  flight  at  700  ft 

12.  VCO:  Reduce  EM  throttle  constant  is  directed  by  SP 

13.  VCO:  Record  trim  throttle  position,  trim  airspeed,  and  engine  speed 

14.  HEO:  Activate  Crossover  switch 

15.  SP/VCO:  Verify  autopilot  has  control  of  aircraft 

16.  HEO:  Deactivate  Crossover  switch 

17.  SP/VCO:  RPA  in  back  in  manual  control  (back  to  Dual  Mode) 

18.  VCO:  Switch  to  ICE  only  mode 

19.  HEO:  Activate  crossover  switch 

20.  HEO:  Verify  EM  off 

21.  SP/VCO:  Monitor  RPA  under  autopilot  control  for  10+  min  flight,  set  to  cruise  velocity 

22.  HEO:  Activate  Crossover  switch 

23.  SP:  Recover/Land  RPA 

24.  VCO:  Place  VC  in  Safe  Mode 

25.  HEO:  Record  engine  stop  time  and  ending  fuel  state 

26.  VCO/HEO/SP:  Proceed  to  Card  FT-06 


ICE  Start  Time: 

Trim  Airspeed:_ 
%  Throttle  trim: 
Engine  Speed: _ 


Engine  stop  time: 
Final  Fuel  State: 
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20.  FT-06:  CONDOR  Endurance  Test  Card 


Preconditions: 

Completion  of  FT-05 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  12-ft, _ -lbs,  18x10  2-blade  prop 

Objective: 

Verify  HE  can  transition  manual  control  to  autopilot  and  evaluate  endurance  performance 


FT-06:  PROCEDURES 

1.  SO:  Ensure  fire  safety  and  test  safety  measures  in  place 

2.  VCO:  Ensure  CONDOR  P1D  Values  uploaded  ,  and  waypoints/rally  points  loaded  into 
VC 

3.  VCO:  Ensure  VC  in  Safe  Mode  prior  to  HE-RPA  startup 

4.  HEO:  Record  starting  fuel  level  of  RPA 

5.  HEO:  Record  starting  battery  voltage  and  current  draw 

6.  VCO:  Perform  Pre-engine  start-up  portion  of  Launch  Checklist 

7.  VCO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  “Manual  Mode” 

8.  HEO:  Conduct  HE-RPA  startup  checklist,  record  ICE  start  time 

9.  VCO:  Set  VC  HE  add-in  to  Dual  Mode  (EM  Boost),  ICE  throttle  constant  (-40%) 


Notes: 


Starting  Fuel  Level: 


Starting  battery  voltage: 
Draw: _ 


Dur:  30  min 


Starting  Current 
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FT-06:  PROCEDURES 

10.  SP:  Launch  aircraft 

11.  SP:  Trim  the  CONDOR  for  level  flight  at  700  ft 

12.  VCO:  Reduce  ICE  throttle  constant  is  directed  by  SP 

13.  VCO:  Record  trim  throttle  position,  trim  airspeed,  and  engine  speed 

14.  SP/VCO:  RPA  in  back  in  manual  control  (back  to  Dual  Mode) 

15.  VCO:  Switch  to  EM  only  mode 

16.  HEO:  Verify  ICE  idle 

17.  SP/VCO:  Monitor  RPA  under  autopilot  control  for  10+  min  flight,  set  to  endurance 
velocity 

18.  SP:  Recover/Land  RPA 

19.  VCO:  Place  VC  in  Safe  Mode 

20.  HEO:  Record  engine  stop  time  and  ending  fuel  state  and  required  battery  charge 

21.  VCO/HEO/SP:  Proceed  to  Card  FT-06 
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Notes: 


Dur:  30  min 


ICE/EM  Start  Time: 

Trim  Airspeed: _ 

%  Throttle  trim: _ 

Engine  Speed: _ 


Engine  stop  time: _ 

Final  Fuel  State: _ 

Required  Battery  Charge: 


21.  FT-07:  CONDOR  HE  ReGen  Mode  &  Kill  Switch  Test  Card 


Preconditions: 

Completion  of  GT-06 

Note:  Mission  requires  a  Safety  Observer  (SO),  HE  System  operator  (HEO),  and  Virtual  Cockpit  operator  (VCO).  The  entire  test  will  be  conducted  in 
Manual  Mode 

CONDOR  Configuration:  12-ft, _ -lbs,  18x10  2-blade  prop 

Objective: 

Verify  HE  EM  ReGen  and  ICE  Kill  switch  function  correctly 


FT-07:  PROCEDURES 


Notes: 


HE  System  ReGen  Verification 

1.  SO:  Ensure  fire  safety  and  test  safety  measures  in  place 

2.  VCO:  Ensure  Condor  PID  Values  uploaded  ,  and  waypoints  loaded  into  VC 

3.  VCO:  Ensure  VC  in  Safe  Mode  prior  to  HE-RPA  startup 

4.  HEO:  Record  battery  starting  battery  voltage  &  current,  ensure  at  least  2V  under  max 

5.  HEO:  Record  starting  fuel  level  ofRPA 

6.  VCO:  Perform  Pre-engine  start-up  portion  of  Launch  Checklist 

7.  VCO:  Verify  RC  Mode  (control  boxes  grayed  out)  and  in  “Manual  Mode” 

8.  VCO:  Place  VC  HE  add-in  to  ICE  Only 

9.  HEO:  Conduct  HE-RPA  startup  checklist,  record  ICE  start  time 


Starting  Battery  Voltage: 
Current: _ 

Starting  Fuel  Level: _ 


Dur:  30  min 


Starting 
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FT-07:  PROCEDURES 


10.  VCO:  Set  VC  HE  add-in  to  Dual  Mode  (ICE  Boost),  EM  throttle  constant  (-30%) 

11.  SP:  Accelerate  RPA  to  approximated  cruise  speed  (or  appropriate  for  safe  grnd  ops) 

12.  SP:  Begin  test  laps  with  RPA 

13.  VCO:  Reduce  EM  throttle  constant  is  directed  by  SP 

14.  VCO:  Record  trim  throttle  position,  trim  airspeed,  and  engine  speed 

15.  VCO:  Set  VC  add-in  to  ICE  only  Mode 

16.  HEO:  Verify  EM  off 

17.  HEO:  Record  Battery  pack  voltage  &  ReGen  start  time 

18.  VCO:  Set  VC  add-in  to  Regen  Mode 

19.  HEO:  Maneuver  RPA  in  lap  pattern  &  monitor  battery  pack  voltage,  record  time  for 
voltage  to  increase  0.5V 

20.  VCO:  Place  VC  HE  add-in  to  ICE  Only 

**Simulated  -  HIGH  RISK** 

ICE  Kill  for  Silent  Operation 

21.  VCO:  Set  VC  add-in  to  EM  Mode 

22.  HEO:  Verify  EM  powers  up  &  ICE  goes  to  idle 

23.  SP:  Verify  EM  throttle  response,  prepare  for  simulated  emergency  landing 

24.  HEO:  Activate  ICE  Kill  Switch 

25.  HEO:  Verify  ICE  killed  &  Record  engine  stop  time 

26.  SP:  Verify  RPA  performance  under  EM  only  mode  (no  ICE) 

EM  Kill  verification 
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Notes: 


Dur:  30 


Start  Engine  Start  Time: 


Battery  Voltage: _ Start  ReGen 

Time: _ 


End  ReGen  Time: 


Engine  stop  time: 


FT-07:  PROCEDURES 

27.  HEO:  Activate  EM  kill  switch  just  prior  to  touchdown 

28.  SP:  Recover  **Simulated  Dead  stick  Landing”” 

29.  VCO:  Place  VC  in  Safe  Mode 

30.  HEO:  Record  final  fuel  state 

31.  VCO/HEO/SP:  End  Testing 
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Notes: 


Dur:  30  min 


Final  Fuel  State: 
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Appendix  J.  Qualitative  Risk  Assessment 


Flight  Test  Approval 

•  Description 

In  order  to  fly  a  UAV,  Federal  Aviation  Administration  (FAA)  and  military 
requirements  must  be  met.  Since  the  RPAs  were  being  built  using  OSD  funding, 
USAF/AFRL  requirements  did  not  apply  to  the  unmodified  version  of  the  RPA.  Since 
AFRL  funding  was  used  to  develop  the  HE  system,  the  HE -RPA  may  have  required 
approval  from  AFRL  prior  to  all  flight  tests. 

•  Planned  Mitigation  efforts 

We  planned  to  fly  the  unmodified  RPA  and  HE-RPA  in  restricted  airspace  so  that 
there  were  fewer  FAA  restrictions.  We  also  worked  with  AFRL  subject  matter  experts 
and  other  AFIT  organizations  that  had  used  the  AFRL  process  to  leam  of  possible 
pitfalls. 

•  Impact 

Without  AFRL  approval,  we  may  not  have  been  able  to  fly  the  HE-RPA.  Even 
with  AFRL  approval,  flight  tests  may  have  been  delayed  due  to  “red  tape”. 

•  Reults 

Working  with  AFRL  ahead  of  time  assisted  in  clarifying  the  AFRL  involvement  in 
the  project.  AFRL  decided  that  since  AFRL  funds  were  only  used  for  HE  development, 
and  not  directly  used  for  flight  testing,  AFRL  approval  was  not  required  for  the  flight 
testing. 
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HE  development/Configuration 


•  Description 

The  HE  system  had  not  yet  run  with  the  gas  and  electric  motors  working  in 
tandem.  The  configuration  of  the  HE  system  that  would  eventually  be  integrated  into  the 
modified  RPA  had  not  been  determined  at  project  initiation.  The  HE  configuration  could 
have  impacted:  noise,  weight,  efficiency,  thrust  etc. 

•  Planned  Mitigation  efforts 

This  was  a  primary  portion  of  the  hybrid-electric  research.  Additional  team 
members  were  hired  to  continue  to  develop  the  HE  system  and  have  it  running  in  the 
intended  configuration  of  the  HE-RPA  prior  to  delivery  of  the  Condor  airframes.  The  HE 
system  was  also  primarily  comprised  of  commercial  off  the  shelf  (COTS)  components 
resulting  in  a  shorter  planned  development  time. 

•  Impact 

HE  development  and  system  configuration  was  critical  to  this  project  and  poor  planning 
and  execution  here  could  have  impacted  cost,  schedule,  and  performance. 

•  Reults 

The  additional  team  members  were  unable  to  fully  develop  the  HE  system  in 
accordance  with  the  pre-planned  schedule,  because  the  maturity  of  the  HE  technology 
development  was  not  as  high  as  originally  understood.  There  were  also  many  unforeseen 
setbacks  in  the  development  and  integration  of  the  HE  system  that  are  discussed  in  detail 
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by  Ausserer  [12].  Although  using  COTS  hems  assisted  in  reducing  HEPS  development 
cost  and  schedule,  they  were  also  used  in  ways  that  were  not  intended  by  the  original 
equipment  manufacturer  (OEM),  causing  many  of  the  unforeseen  setbacks. 


Risk  of  crashing  an  airplane 

•  Description 

As  with  all  aviation  systems,  there  was  a  risk  of  crashing  one  or  both  RPAs. 
Since  program  funding  was  limited,  it  was  not  feasible  to  have  spare  RPAs  available  in 
case  of  catastrophic  failure.  It  was  initially  anticipated  that  the  HE-RPAs  would  have 
hard  landings  since  there  was  a  plan  to  use  fall-away  landing  gear. 

•  Planned  Mitigation  efforts 

The  flight  test  approval  activities  were  modeled  after  the  AFRL  process  for  the 
unmodified  RPA.  By  following  the  value  added  portions  of  the  AFRL  flight  test 
approval  process,  the  HE-RPA  development  team  planned  to  mitigate  flight  risk  via 
simulation  and  quality  test  planning. 

By  having  two  identical  RPAs  to  work  with,  program  risk  could  have  been 
reduced  by  utilizing  interchangeable  parts  between  the  two  RPAs  so  that  if  a  portion  of 
one  aircraft  were  broken  during  a  rough  landing,  then  a  part  from  the  other  aircraft  could 
have  been  used  to  get  it  back  in  the  air  for  testing.  The  HE-RPA  development  team  also 
planned  to  work  with  CLMax  in  order  to  use  residual  contract  funding  to  procure  spare 
parts  for  contingency  purposes. 
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•  Impact 

Should  both  RPAs  have  had  catastrophic  landings  or  failures  resulting  in  un¬ 
repairable  damage,  then  the  impact  to  some  of  the  test  objectives  would  have  been 
critical.  Test  objectives  were  accomplished  according  to  flight  risk  so  that  less  risky 
objectives  were  accomplished  first.  It  was  expected  that  some  rough  landings  would 
happen.  If  a  rough  landing  happened  during  testing  and  the  RPA  was  not  repairable  in 
the  field,  then  testing  for  that  test  objective  may  have  been  delayed  until  the  next  test 
activity. 

•  Reults 

The  HE-RPA  team  decided  to  keep  the  landing  gear  on  the  aircraft  at  all  times 
mitigating  the  impact  of  rough  landings.  Some  rough  landings  occurred  and  the  spare 
parts  provided  by  CLMax  assisted  in  repairing  the  aircraft  in  time  for  the  next  test  event. 
By  prioritizing  test  activities  and  accomplishing  lower  risk  tests  first,  the  rough  landings 
that  did  occur  did  not  cause  significant  schedule  delays.  By  analyzing  the  cracks  caused 
by  rough  landings,  the  team  determined  areas  where  the  aircraft  required  more  structural 
integrity.  Between  flight  test  events,  the  aircraft  structure  was  reinforced  to  protect 
against  damage  caused  during  future  rough  landings. 


Further  Fabrication  Shop  Delays 

•  Description 
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The  original  version  of  the  RPA  was  to  be  built  by  CLMax.  If  there  were  a  delay 
in  the  fabrication  of  the  RPA  then  it  could  have  caused  a  program  delay. 

•  Planned  Mitigation  efforts 

The  HE-RPA  development  team  planned  to  work  with  CLMax  to  ensure  that  the 
parts  that  we  required  early  in  the  schedule  were  manufactured  first.  The  team  also 
planned  on  getting  regular  progress  updates  from  CLMax. 

•  Impact 

Based  on  the  initial  schedule,  RPA  delivery  was  not  on  the  critical  path  and  so 
some  delay  was  acceptable. 

•  Reults 

Labrication  of  the  RPA’s  was  delayed  but  did  not  get  on  the  critical  path.  The 
team  requested  that  the  fuselage  of  the  HE-RPA  be  sent  earlier  in  order  to  expedite  the 
integration  of  the  HE  system  in  the  fuselage.  The  fuselage  that  was  shipped  ended  up 
being  an  extra  fuselage  that  was  used  to  repair  the  aircraft  after  several  rough  landings. 
Although  the  extra  fuselage  was  ordered  to  mitigate  the  integration  risk,  it  actually 
mitigated  the  risk  of  rough  landings  and  did  not  result  in  mitigation  to  the  integration 
schedule  risk. 

When  discussing  the  progress  of  airframe  fabrication  with  CMax,  CLMax 
explained  that  after  several  flight  test  attempts,  the  fabrication  prototype  aircraft  did  not 
fly.  CLMax  requested  more  time  to  develop  the  airframe  so  that  a  two  cycle  engine 
could  be  ordered  and  replaced  in  the  prototype  airframe  for  further  flight  test  events.  The 
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HE-RPA  development  team  detennined  that  the  proposed  schedule  delay  resulting  from 
an  integration  of  a  two  cycle  engine  was  not  worth  the  potential  to  gather  more 
information  about  the  prototype  airframe. 

The  development  team  knew  that  the  airfoil  being  used  was  a  proven  airfoil  and 
was  stumped  as  to  why  the  prototype  airframe  did  not  fly.  The  team  requested  that 
CLMax  deliver  the  airframes  as  planned  even  though  the  flight  potential  was  unproven. 
The  team  decided  toaccept  the  technical  risk  of  having  an  unproven  airframe  in  exchange 
for  the  shorter  delivery  schedule.  The  team  felt  that  the  group  of  aeronautical  engineers 
involved  in  the  project  with  the  assistance  of  aeronautical  engineering  professors  and 
CESI  support  contractors  would  be  able  to  get  the  airframe  to  fly.  The  team  knowingly 
agreed  to  pay  CLMax  for  two  airframes  that  may  never  fly  and  understood  that  the 
majority  of  test  objectives  would  not  be  accomplished  if  the  airframes  were  not  capable 
of  flying. 
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Feedback  Control 


•  Description 

The  HE-RPA  needed  to  be  controllable  during  flight  tests.  As  this  was  a  new 
platform,  the  feedback  control  was  expected  to  be  nontrivial. 

•  Planned  Mitigation  efforts 

The  HE-RPA  development  team  assumed  that  CLMax  would  design  the  original 
feedback  control  of  the  RPA  as  part  of  RPA  development.  As  control  is  an  iterative 
process,  the  team  planned  to  first  tune  the  control  loops  of  the  original  RPA  prior  to 
tuning  the  control  loops  of  the  HE-RPA. 

•  Impact 

According  to  the  initial  schedule,  feedback  control  should  not  have  had  a  great 
impact  on  the  program  schedule  but  could  have  impacted  the  flight  test  schedule. 

•  Reults 

CLMax  was  not  able  to  successfully  get  the  aircraft  off  the  ground  prior  to 
delivery  of  the  aircraft.  The  fuselage  fabrication  was  delayed  several  months  and  CLMax 
requested  additional  time  to  try  a  different  engine.  The  HE-RPA  team  decided  to  request 
that  CLMax  deliver  the  Condor  air  frames  and  let  the  team  figure  out  how  to  get  them  off 
the  ground  after  delivery.  Since  CLMax  never  flew  the  Condor,  CLMax  did  not  assist  in 
the  design  of  the  feedback  control  of  the  Condor  aircraft.  Giacomo  [13]  discusses  the 
development  of  the  feedback  control,  via  control  loop  tuning,  of  the  Condor. 

Development  of  the  feedback  control  did  not  delay  the  development  of  the  HE-RPA  since 
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Giacomo  was  able  to  tune  the  gains  for  the  ICE  RPA  at  the  weight  of  the  HE-RPA  and 
use  those  gains  for  the  HE-RPA. 


Propeller  Type 

•  Description 

It  was  expected  that  some  propellers  were  more  likely  to  break  during  landing  and 
some  propellers  were  quieter  than  others. 

•  Planned  Mitigation  efforts 

The  HE-RPA  development  team  researched  propeller  noise  based  on  propeller 
type  and  will  used  a  quiet  propeller  that  was  inexpensive  so  that  we  can  afford  to  have 
spare  propellers  during  testing. 

•  Impact 

Propeller  noise  could  have  had  a  significant  impact  on  mission  perfonnance. 
Propeller  type  may  have  had  a  minimal  impact  on  cost  if  they  break  during  landings  more 
often  than  expected. 

•  Results 

A  test  stand  was  set  up  to  test  the  noise  of  potential  propellers.  Propeller  noise 
continues  to  be  an  issue  with  regards  to  the  quiet  operation  of  the  HE-RPA.  Although  the 
engine  noise  can  be  reduced  using  an  HEPS,  the  propeller  noise  will  continue  to  be  an 
issue. 
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1.  PART  I  -  INTRODUCTION 


1.1.  Purpose. 

The  purpose  of  this  TEMP  is  to  set  forth  the  planning  and  actions  required  to 
evaluate  the  effectiveness  of  the  Condor  Remotely  Piloted  Aircraft  (RPA),  a  small 
unmanned  air  vehicle  powered  by  a  hybrid-electric  propulsion  system.  This  submission  is 
the  initial  version  of  the  TEMP.  This  TEMP  is  intended  to  support  a  potential  Milestone- 
A  decision;  associated  with  an  Air  Force  Institute  of  Technology  Systems  Engineering 
Master’s  Degree  program.  Testing  is  intended  to  evaluate  performance  characteristics 
documented  in  the  Hybrid-Electric  RPA  CONOPS. 

1.2.  Mission  Description. 

The  proposed  concept  is  intended  to  fulfdl  the  need  for  a  forward  deployed,  near- 
silent,  ISR  collection  platform  capable  of  providing  sustained  ISR  data  collection  for 
utilization  in  planning,  real  time  operations,  or  post  operation  analysis.  The  concept  is 
intended  to  utilize  payloads  designed  for  low  altitude  operations,  while  being  operated 
from  a  safe  standoff  distance.  Units  equipped  with  the  system  are  anticipated  to  operate 
the  system  in  accordance  with  the  included  OV-1  illustrated  in  the  CONOPS  (ref)  and 
system  architecture  (ref). 


OV-1 :  Hybrid-Electric  RPA  Operational  Concept 
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1.3.  System  Description. 

The  HE-RPA  will  consist  of  a  glider-like  airframe  with  both  12  and  15  foot 
wingspan  configurations.  The  project  will  have  two  airframes,  one  with  a  hybrid-electric 
propulsion  system  and  one  with  an  internal  combustion  engine  (ICE).  The  purpose  of  the 
aircraft  with  the  ICE  propulsion  system  will  be  to  provide  a  performance  baseline  against 
which  the  hybrid-electric  airframe  will  be  compared.  The  ICE-RPA  will  consist  of  the 
ICE  propulsion  system,  the  basic  airframe,  the  Kestral  Autopilot,  a  gas  tank,  and  an 
onboard  camera.  The  HE-RPA  will  consist  of  the  HE  propulsion  system,  the  basic 
airframe,  the  Kestral  Autopilot,  the  gas  tank,  an  onboard  camera,  LiPo  Batteries,  and  the 
engine  throttle  and  mode  controller. 

1.3.1.  System  Threat  Assessment. 

In  an  operational  environment,  the  HE-RPA  will  be  exposed  to  environmental 
hazards  as  well  as  enemy  small  arms  fire  and  counter  measures.  The  as-built 
configurations  will  not  include  any  form  of  communications  or  data  link  security 
measures,  leaving  the  system  vulnerable  to  signal  pirating  and/or  hacking.  The  enemy 
may  be  able  to  duplicate  the  ground  control  protocol  and  take  control  of  the  aircraft  in  the 
as-built  configuration.  IT  is  anticipated  that  HE-RPA  communication  protocols  will  be 
secure  in  the  as-intended  configuration  and  comply  with  Defense  Intelligence  Agency 
mandated  measures. 

1.3.2.  Program  Background. 

Although  this  effort  is  primarily  focused  on  determining  the  potential  operational 
viability  of  a  HE-RPA  concept  as  a  master’s  level  academic  program,  the  basis  for  the 
project  lays  in  several  PhD  and  masters  level  research  efforts  done  at  UC  Davis,  AFIT, 
and  AFRL.  These  previous  efforts  were  primarily  focused  on  airframe  and  propulsion 
system  development  and  optimization.  Due  to  the  academic  environment  in  which  the 
HE-RPA  will  be  developed,  the  academic  portion  of  this  project  will  be  accomplished  by 
producing  and  evaluating  a  unique  configuration,  the  “as-built”  configuration,  and 
extending  that  evaluation  to  an  “as-intended”  or  potentially  operational  configuration. 

The  “as-built”  configuration  will  be  a  simplified  version  of  the  “as-intended” 
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configuration.  This  project  will  serve  as  a  proof  of  concept  to  determine  if  the  HE-RPA 
concept  is  a  viable  alternative  for  long  loiter  near-silent  ISR  collection  operations.  It  is 
anticipated  that  future  students  may  further  develop  this  concept. 

1.3. 2.1.  Previous  Testing. 

Many  of  the  individual  components  comprising  the  HE  propulsion  system  have 
been  tested.  The  HE  propulsion  system  is  currently  under  development  at  AFIT  with 
assistance  from  AFRL  and  has  completed  some  initial  ground  testing  for  some  of  the 
operating  modes.  Initial  ground  testing  of  the  camera  has  also  been  accomplished.  The 
provider  of  the  airframe,  CLMax,  has  built  a  prototype  of  the  ICE-RPA  platfonn  but 
unable  to  get  it  off  the  ground  during  initial  flight  testing.  The  airframe  testing  results 
thus  far  have  led  to  the  parallel  development  of  a  catapult  launch  system  and  the 
necessary  test  planning. 


1.3.3.  Key  Capabilities. 


KPP 

Threshold 

Objective 

1 .  HE-RPA  quieter  than 
Existing  ICE-RPAs 

HE-RPA  noise  level  equal  to 
ICE  RPA  idle  noise  level 

HE-RPA  noise  level  less  than 
70dB 

2.  Loitering  time 

exceeding  unmodified 
ICE-RPA 

HE-RPA  loiter  time 
exceeding  ICE  idle  fuel  bum 
rate  for  60oz 

HE-RPA  loiter  time  doubling 
ICE  idle  fuel  bum  rate  for 

60oz 

3.  Loitering  time 

comparable  to  existing 
ICE-RPAs 

HE-RPA  loiter  time  30-min 

HE-RPA  loiter  time  2  hours 

4.  Runway  Takeoff 
Distance 

150  ft.  (use  of  catapult  okay) 

120  ft.  without  catapult 
assistance 

1.3. 3.1.  Key  Interfaces. 

Successful  operation  of  the  HE  RPA  requires  interfacing  of  key  elements  including  both 
system  and  non-system  components.  These  key  system  and  non-system  elements  are 
shown  in  Table  1  and  depicted  in  the  Systems  Viewpoint  1  (SV-1)  of  the  systems 
architecture. 
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Table  1:  System  Elements 


System  Elements 

Non-System  Elements 

Aircraft 

Command  and  Control 

Ground  Control  Station 

Global  Positioning  System 

(GPS) 

Manual  Backup  Control 

Environment 

Operator 

(SV-1) 


1.3. 3.2.  Special  test  or  certification  requirements.  N/A 


1.3. 3. 3.  Systems  Engineering  (SE)  Requirements. 

Due  to  the  project  duration,  the  system  under  development  will  only  attain  a 
prototype  status.  Therefore,  testing  will  be  limited  to  Type  1  testing  per  Blanchard  and 
Fabrycky  2011.  Type  1  testing  is  tailored  towards  evaluating  engineering  test  models, 
system  components,  breadboards,  mock-ups,  and  rapid  prototyping.  The  systems 
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engineering  plan  (SEP)  is  tailored  to  allow  for  incremental  component  development  and 
test,  culminating  in  overall  [prototype]  system  test  and  evaluation  (T&E).  System 
evaluation  targets  will  derived  from  SE-based  infonnation  including  the  initial  system 
level  requirements,  measures  of  effectiveness  (MOEs)  (ref),  key  performance  parameters 
(KPPs)  (ref),  and  subsystem/component  specifications  (ref). 


2.  PART  II  -  TEST  PROGRAM  MANAGEMENT  AND  SCHEDULE 
2,1  T&E  Management. 

All  test  management  activities,  to  include  planning,  scheduling,  resource 
allocation,  and  documentation  will  be  the  responsibility  of  and  conducted  by  AFIT 
graduate  students  fulfilling  roles  of  government  developmental  testers. 

Initial  developmental  testing  of  a  base  airframe  will  be  conducted  by  the  contractor, 
CLMax.  The  contractor  is  responsible  for  delivering  an  airworthy  vehicle  capable  of 
incorporating  the  hybrid-electric  propulsion  system.  Results  of  this  preliminary  testing 
will  be  utilized  for  further  HE-RPA  prototype  development  and  flight  control 
optimization. 

Additionally,  graduate  students  from  AFIT  along  with  local  undergraduate  interns 
will  fabricate  the  hybrid-electric  propulsion  system  and  conduct  developmental  testing. 
The  results  of  the  propulsion  system  testing  will  be  used  to  validate  previous  HE-RPA 
analyses,  the  feasibility  of  multi-mode  operation,  and  the  potential  viability  of  a  proposed 
operational  concept. 

Flight  testing  and  vehicle  ground  testing  will  be  accomplished  by  graduate 
students  with  support  provided  by  CESE  (ref),  an  engineering  support  contractor.  The 
support  contractor  is  responsible  for  providing  safety  pilots,  basic  flight  test  support, 
visual  spotting,  ground  station  setup,  and  basic  vehicle  and  support  equipment 
maintenance. 
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2.1.1.  T&E  Organizational  Construct. 

Key  testing  activities  and  the  associated  organizational  construct  for  the  testing  is 
depicted  below.  System  testing  will  essentially  fall  into  one  of  three  broad  divisions; 
Hybrid-Electric  propulsion  system  developmental  test,  airframe/vehicle  testing,  and 
system  integration  testing.  Testing  will  be  limited  to  developmental  in  scope.  No  follow- 
on  OT&E  is  planned  nor  is  any  LFT&E  necessary  or  planned  as  this  is  an  unmanned 
system.  Testing  has  also  been  organized  in  such  a  manner  as  to  facilitate  the  necessary 
division  of  labor  and  scope  needed  for  specific  yet  various  AFIT  master’s  degree 
requirements. 


2.2.  Common  T&E  Database  Requirements. 

Testing  will  be  documented  in  accordance  with  specifics  detailed  in  specific  test 
plans  and  per  pre-determined  developmental  testing  criteria.  T&E  data  will  be  stored  in 
the  AFIT  shared  Condor  file  at  L:\Students\Groups\GSE_Group_Research\Condor. 
Results  of  testing  and  the  final  concept  evaluation  will  also  be  documented  in  the 
pertinent  AFIT  master’s  theses. 

2.3.  Deficiency  Reporting 

Deficiencies  will  be  reported  and  documented  IAW  test  plans  and  after  action 
reports/summations.  Dissemination  will  be  via  update  emails  or  during  weekly  project 
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reviews.  The  reports  will  include  a  description  of  the  problem  as  well  as  one  or  more 
proposed  solutions. 

2.4.  TEMP  updates 

The  latest  version  of  the  TEMP  will  be  posted  in  the 
L:\Students\Groups\GSE_Group_Research\Condor  file.  The  TEMP  will  be  used  as  a 
“living”  document  and  will  be  updated  as  required  throughout  the  project.  The  TEMP 
will  be  reviewed  prior  to  all  scheduled  testing 
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2.5.  Integrated  Test  Program  Schedule. 
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3.  PART  III  -  TEST  AND  EVALUATION  STRATEGY 


3.1  T&E  Strategy 

The  primary  purpose  of  testing  this  system  is  to  collect  infonnation  needed  to 
generate  a  concept  evaluation  for  a  remotely  piloted  aircraft  powered  by  a  hybrid-electric 
propulsion  system.  Testing  will  also  facilitate  a  piecemeal  evaluation  of  component 
technologies  including  the  standalone  hybrid-electric  propulsion  system,  the  RPA 
platform,  the  ground  control  station,  and  the  control  logic/strategies.  Testing  will  also 
contribute  to  the  development  of  future  employment  tactics  for  this  system. 

The  concept  evaluation  could  potentially  support  a  transition  of  the  system  into  an 
official  acquisition  program  (pre  milestone  A)  or  it  may  contribute  to  the  future 
development  and/or  advancement  of  related  technologies. 

Testing  will  follow  a  sound  progression  in  order  to  maximize  component 
availability  and  to  minimize  the  impact  of  unanticipated  results  or  findings.  The  risk 
levels  associated  with  testing  will  progressively  increase  with  the  subsequent  completion 
of  test  events.  Initial  testing  will  be  at  the  M&S  level,  followed  by 
component/breadboard  levels,  then  evolving  into  integrated  system  ground  testing 
(hardware-in-the-loop  testing),  and  finally  culminating  in  flight  testing;  with  the  most 
aggressive  test  calling  for  hazardous  mid-air  engine  restarts. 

Critical  to  overall  system  success,  testing  of  the  Hybrid  Electric  (HE)  motor  will 
be  conducted  during  and  after  initial  and  final  assembly.  Flight  testing  efforts  will  be 
divided  between  two  vehicles.  Aircraft  1,  the  ICE  only  configuration,  will  be  tested  with 
a  weight  and  balance  configuration  mimicking  the  weight  and  balance  properties  to  the 
HE  aircraft.  Lessons  learned  during  the  ICE  aircraft  flight  test  will  be  utilized  in  the  final 
development  and  flight  testing  of  the  HE  aircraft.  Tests  that  pose  little  or  no  threat  to  the 
HE  engine  and/or  the  airframes  will  be  conducted  prior  to  test  points  deemed  to  be  higher 
in  risk. 
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3.2.  Evaluation  Framework. 

Evaluations  of  the  HE-RPA  system  will  focus  on  the  following  aspects  in  order 
characterize  and  evaluate  the  system  against  the  proposed  CONOPS  and  Critical 
Operational  Issues  (COIs). 

(1)  Development  of  the  system  and  processes 

(2)  System  perfonnance  in  a  developmental  context 

(3)  Assessment  of  potential  operational  capabilities 

(4)  Comparison  with  existing  capabilities 

(5)  Maturation  requirements  of  high  risk  technologies 

In  order  to  facilitate  this  system  evaluation,  testing  will  be  conducted  in  order  to 
generate  the  information  needed  to  generate  an  initial  assessment  of  the  system’s 
potential  for  future  development  and/or  operational  use.  System  testing  will  be 
segmented  into  the  three  following  areas: 

Component/hardware-in-the-loop  testing 
Developmental  Ground  Test 
Developmental  Flight  Test 
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Key  Requirements  and  T&E  Measures 


COls 

Key  MOEs/MOSs 

CTPs  &  Threshold 

Test 

Key  Reqs 

(Critical  Operational 

(Measures  of 

(Critical  Technical 

Methodologies/Key 

Resources 

Decision  Supported 

Issues) 

effectiveness/Suitability) 

Parameters) 

KPP#1: 

Time  in  HE-mode 

Acoustic  Chamber 

PDR 

measurement 

CO!#l.  Is  the  HE- 

Engine  and  Prop 
noise 

Outdoor  acoustic 

(Quiet) 

RPA  effective  for 

Decibel  Levels 

ground 

CDR 

quiet  operation 

measurements 

Loiter  Time 

Flight  acoustic 
measurements 

KPP  #2 

COl  #2.  Can  the  HE- 

Regeneration  Time 

PDR 

(Loiter 

comparison) 

RPA  loiter  as  long  as 
a  comparable  ICE 

RPA 

Cruise  Speed 

Loiter  Time 

Flight  measurements 

CDR 

KPP  #3 

COl  #3.  Can  the  HE- 
RPA  and  1CE-RPA 

Time  of  Flight 

Loiter  Time 

Flight  Measurements 

PDR 

(Loiter 

duration) 

loiter  long  enough  to 
complete  a  mission 

Regeneration  Time 

CDR 

Figure  3.1,  Top-Level  Evaluation  Framework  Matrix 
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3.3.  Developmental  Evaluation  Approach. 

Evaluation  and  testing  will  follow  a  progressive  approach  that  coincides  with 
system  maturity  and  an  associated  level  of  risk.  The  projected  test  sequence  and  high 
level  test  objectives  are  detailed  below. 

3.3.1  Component/hardware-in-the-loop  testing 

Testing  will  be  conducted  with  prototype  or  representative  items  in  order  to 
simulate  operational  conditions  and  employment  scenarios.  The  primary  purpose  of  the 
component/hardware-in-the-loop  testing  is  to  observe  system  functionality  and  to  collect 
and  verify  system  data  outputs. 

(1)  HE  engine  test  objectives  -  ICE  engine  basic  function  Software  in  the  loop 
testing 

a.  Torque  Maps 

b.  Fuel  Consumption  Maps 

c.  Verify  Positive  control  of  ICE  with  Motor  Controller 

(2)  Electric  Motor  (EM)  basic  function 

a.  Torque  maps 

b.  Energy  Consumption  Maps 

c.  Verify  positive  control  with  Motor  Controller 

d.  Propeller  Feathering  (get  the  propeller  to  stop  in  the  same  place  very  time) 

(3)  Dual  Mode  Testing 

a.  Verify  torque  switch  strategy 

b.  Ensure  1 -way  bearing  works 

c.  Verify  that  the  motor  can  apply  additional  torque  at  ICE  speed  (well 
matched) 

d.  Verify  that  the  regeneration  strategy  is  appropriate  and  works 

e.  Check  that  power  takeoff  from  engine  meets  recharging  requirement 

f.  Fuel  consumption  maps  under  dual  mode 

g.  Verify  positive  control  of  dual  mode  with  motor  controller 
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(4)  HE  motor  only  acoustic  testing 

a.  Detennine  decibel  levels  for  several  speeds 

b.  Evaluate  effect  of  cooling 

(5)  HE  motor  and  propeller  acoustic  testing 

a.  Detennine  decibel  levels  for  several  speeds 

b.  Detennine  decibel  levels  for  several  prop  configurations 

(6)  HE  motor  endurance  testing 

a.  Detennine  maximum  operational  time  in  HE-mode  without  regeneration 

b.  Detennine  maximum  operational  time  in  HE-mode  with  regeneration 

c.  Detennine  optimal  battery  configuration  and  discharge  strategy 

(7)  Engine  restart 

a.  Verify  ICE  engine  can  be  restarted  after  incremental  shutdown  time 

b.  Verify  ICE  engine  can  be  restarted  via  remote  control/wireless  command 

c.  Verify  engine  can  be  restarted  without  additional  choke  adjustments 

d.  Detennine  system  voltage  drop  due  to  starter  use 

(8)  HE  mode  testing  (ICE  only,  EM  only,  ICE  idle  &  EM  full  throttle,  ICE  and 
EM  full  torque,  ICE  with  EM  recharge) 

a.  Verify  control  of  magnetos  for  propulsion  system  kill 

b.  Verify  control  of  the  starter  motor 

c.  Verify  positive  mode  control  for  both  propulsion  state  and  electric  motor 

(9)  Camera  component  testing 

a.  Detennine  required  voltage  for  camera  switching 

b.  Detennine  optimal  antenna  location  and  configuration 

3.3.2  Developmental  Ground  Testing 

The  primary  purpose  of  the  developmental  ground  testing  is  to  evaluate  the  result 
of  integrating  the  HE  propulsion  system  into  the  airframe  along  with  the  associated 
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system  control  components  and  evaluation  of  the  control  strategies.  Testing  will  also 
focus  on  data  collection  only  possible  via  the  complete  system.  Results  of  the  testing  will 
detennine  the  readiness  of  the  system  for  flight  testing. 

(1)  System  integration  test 

a.  HE  aircraft  and  ICE  aircraft  control  surface  and  throttle  testing 

b.  HE  mode  control  with  all  other  electrical  systems  operating 

c.  Software  in  the  loop  testing  -  automated  mode/emergency  procedures 

d.  Ground  station  testing  and  pre-flight  operations  checks 

(2)  HE  and  ICE  acoustic  testing  -  airframe 

a.  Mounted  in  air 

b.  Radius  on  ground 

(3)  Operator  familiarization  and  training 

a.  Setup  -  operational  checks 

b.  Operation 

c.  Emergency  procedures 

d.  Recovery 

(4)  Camera  testing 

a.  Range 

b.  Camera  switching 
3.3.3  Developmental  Flight  Testing 

The  first  flight  tests  performed  will  be  perfonned  on  a  prototype  aircraft 
developed  by  the  contractor.  The  purpose  of  the  prototype  flight  test  will  be  to  discern 
the  initial  airworthiness  of  the  aircraft.  Prototype  testing  may  be  conducted  solely  at  the 
discretion  of  the  contractor  with  results  being  passed  to  AFIT. 

Additional  flight  test  will  be  perfonned  on  each  of  the  two  airframes  developed,  a 
basic  ICE  only  configuration  and  HE  configuration  with  the  hybrid-electric  propulsion 
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system.  One  objective  of  the  project  is  to  show  how  the  HE  aircraft  compares  to  a  similar 
ICE  aircraft  in  regards  to  quiet  operation,  long  loiter  time,  and  fuel  efficiency.  The 
purpose  of  the  ICE  airframe  is  to  provide  a  control  article  for  this  comparison  and 
provide  spare  parts  if  needed  for  the  HE  airframe. 

The  ICE  airframe  will  be  delivered  in  a  flight  ready  configuration  and  the  HE 
aircraft  will  require  HE  motor  integration  prior  to  flight.  The  HE  aircraft  will  initially  be 
flown  with  a  weight  and  CG  configuration  matching  the  HE  aircraft.  Flight  test  data  will 
be  used  in  final  integration  of  the  HE  propulsion  system  into  the  HE  aircraft.  The  HE 
aircraft  and  the  ICE  aircraft  in  an  out-of-the-box  configuration  will  be  flown  under 
similar  flight  conditions  for  comparative  purposes. 

Finally,  the  HE  aircraft  will  undergo  additional  flight  testing  in  order  to  evaluate 
the  enhanced  capabilities  of  the  HE  propulsion  system. 

(1)  Tests  to  be  conducted  with  both  aircraft  configurations 

a.  Ground  takeoff 

b.  Catapult  takeoff  (if  required) 

c.  Flight  mode  test  (taxi,  launch,  climb,  cruise,  loiter,  recharge,  land) 

d.  PID  loop  shaping  (longitudinal  and  lateral  mode  testing) 

e.  Camera  tests 

f.  Endurance  testing 

g.  Operator  familiarization  and  training 

h.  Software  in  the  loop 

i.  Contingency  testing  (ex.  communication  out) 

j .  Acoustic  testing  at  altitude 

k.  Kestral  fuel  flow  meter 

(2)  Specific  tests  to  be  conducted  with  ICE  aircraft  configured  with  HE 
weight  and  CG 

a.  Maximum  takeoff  weight  detennination 

b.  HE  mode  thrust  requirement  detennination 
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(3)  Specific  tests  to  be  conducted  with  HE  aircraft 

a.  Fly  with  different  numbers  of  batteries  (conlig  detennination  and  control) 

b.  Aerial  restart 

c.  Maximum  endurance 

d.  In-flight  mode  switching 

e.  Remote/auto  mode  switching 

3.4  Test  Event  and  Test  Resource  summary 


Table  3.1  summarizes  all  planned  test  events,  timing,  and  the  anticipated  test 
location.  A  breakdown  of  specific  test  objective  for  each  event  follows. 

Table  3.1  Test  Event  and  Test  Resource  Summary 


Fiscal  Year 

11 

11 

11 

11 

11 

12 

12 

TBD 

TEST  EVENT 

<N 

CO 

to 

so 

r- 

< 

< 

< 

< 

< 

< 

< 

H 

H 

H 

H 

H 

H 

H 

TEST  RESOURCE 

Dynamometer  Lab 

X 

AFIT/WPAFB  ground  test 

X 

Camp  Atterbury 

X 

X 

X 

X 

WPAFB  acoustic  test  chamber 

X 

(1)  TEST  EVENT:  IT-A1 

Location:  Ground  testing  of  the  HE  propulsion  system  will  be  done  in  the  dynamometer 
lab 

Tests: 

a.  ICE  engine  basic  function  Software  in  the  loop  testing 
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b.  Electric  Motor  (EM)  basic  function 

c.  Dual  Mode  Testing 

d.  HE  motor  endurance  testing 

e.  Engine  restart 

f.  HE  mode  testing  (ICE  only,  EM  only,  ICE  idle  &  EM  full  throttle,  ICE 
and  EM  full  torque,  ICE  with  EM  recharge) 

Test  Objectives: 

a.  Torque  Maps 

b.  Fuel  Consumption  Maps 

c.  Verify  Positive  control  of  ICE  with  Motor  Controller 

d.  Torque  maps 

e.  Energy  Consumption  Maps 

f.  Verify  positive  control  with  Motor  Controller 

g.  Propeller  Feathering  (get  the  propeller  to  stop  in  the  same  place  very  time) 

h.  Verify  torque  switch  strategy 

i.  Ensure  1 -way  bearing  works 

j.  Verify  that  the  motor  can  apply  additional  torque  at  ICE  speed  (well 
matched) 

k.  Verify  that  the  regeneration  strategy  is  appropriate  and  works 

l.  Check  that  power  takeoff  from  engine  meets  recharging  requirements 

m.  Fuel  consumption  maps  under  dual  mode 

n.  Verify  positive  control  of  dual  mode  with  motor  controller 

o.  Verify  control  of  magnetos  for  propulsion  system  kill 

p.  Verify  control  of  the  starter  motor 

q.  Verify  positive  mode  control  for  both  propulsion  state  and  electric  motor 
(2)  TEST  EVENT:  IT-A2 

Location:  Acoustic  ground  test  will  primarily  be  conducted  at  WPAFB  and  will  consist  of 
indoor  and  outdoor  testing. 

Tests: 

a.  HE  and  ICE  acoustic  testing  in  an  open  space  outdoors 

b.  HE  and  ICE  acoustic  testing  while  mounted  in  the  air 


239 


Test  Objectives: 

a.  The  HE  motor  will  be  tested  in  each  mode  with  and  without  the  propeller 
and  will  be  compared  to  the  acoustic  test  of  the  ICE  engine  with  and 
without  the  propeller 

b.  The  HE  motor  will  be  tested  in  each  mode  with  and  without  the  propeller 
and  will  be  compared  to  the  acoustic  test  of  the  ICE  engine  with  and 
without  the  propeller 


(3)  TEST  EVENT:  IT-A3 

Location:  Flight  testing  will  be  done  at  Camp  Atterbury,  IN  using  restricted  air  space. 
The  flight  tests  are  ordered  to  minimize  Program  Risk.  Prior  to  flight  test,  the  HE  and 
ICE  aircraft  will  undergo  system  integration,  operator  familiarization  and  training, 
camera  testing  and  control  surface  verification. 

Tests: 

a.  Initial  ICE-RPA  PID  loop  shaping  test  in  HE  weight  and  balance 
configuration 

b.  Subsequent  ICE-RPA  testing  after  PID  control  is  acceptable 
Test  Objectives: 

a.  Ground  takeoff 

b.  PID  loop  shaping  (longitudinal  and  lateral  mode  testing) 

c.  Operator  familiarization  and  training 

d.  Software  in  the  loop 

e.  Camera  tests 

f.  Kestral  fuel  flow  meter 

g.  Catapult  takeoff  (if  required) 

h.  Flight  mode  test  (taxi,  launch,  climb,  cruise,  loiter,  land) 

i.  Contingency  testing  (ex.  communication  out) 

j .  Acoustic  testing  at  altitude 

k.  Maximum  takeoff  weight 

l.  Endurance  testing 

(4)  TEST  EVENT:  IT-A4 

Location:  EM  testing  of  the  HE  propulsion  system  in  an  indoor  acoustic  testing  facility 
Tests: 
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a.  HE  configuration  acoustic  testing 

Test  Objectives: 

a.  The  EM  motor  will  be  run  with  and  without  the  propeller  and  acoustic 
measurements  will  be  taken  to  determine  the  minimum  attainable  noise  of  the 
HE-RPA. 


(5)  TEST  EVENT:  IT-A5  thru  IT-A7 

Location:  Flight  testing  will  be  done  at  Camp  Atterbury,  IN  using  restricted  air  space. 
Flight  tests  will  be  ordered  to  minimize  Program  Risk. 

Tests: 

b.  Initial  HE-RPA  PID  loop  shaping  test 

c.  Subsequent  HE-RPA  tests 

d.  ICE-RPA  PID  loop  shaping  test  in  “out  of  the  box”  configuration 

e.  Subsequent  ICE-RPA  perfonnance  testing  after  PID  control  is  acceptable 
Test  Objectives: 

a.  Ground  takeoff 

b.  PID  loop  shaping  (longitudinal  and  lateral  mode  testing) 

c.  Operator  familiarization  and  training 

d.  Software  in  the  loop 

e.  Camera  tests 

f.  Catapult  takeoff  (if  required) 

g.  Contingency  testing  (ex.  communication  out) 

h.  Acoustic  testing  at  altitude 

i.  Fly  with  different  numbers  of  batteries  (configuration  determination  and 
control) 

j .  Aerial  restart 

k.  Endurance  testing 

l.  Kestral  fuel  flow  meter 

m.  Flight  mode  test  (taxi,  launch,  climb,  cruise,  loiter,  land) 

n.  Maximum  takeoff  weight 

o.  Endurance  testing 
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3.3.1.  Mission-Oriented  Approach. 

Testing  will  focus  on  the  KPPs  as  they  are  critical  to  achieving  the  capabilities 
covered  in  the  CONOPS.  Currently  only  a  developmental  system,  evaluation  of  the 
KPPs  will  determine  the  achieved  technological  maturity  level  and  hence  suitability  for 
future  operational  employment. 

3.3.2.  Developmental  Test  Objectives. 

The  primary  purpose  of  developmental  test  has  been  to  show  proof  of  concept. 

By  exploring  the  trade  space  of  the  technology  under  development  future  decision  makers 
will  be  able  to  consider  this  technology  as  part  of  an  analysis  of  alternatives. 

Developmental  test  objectives  coincide  with  key  performance  parameters. 

3.3.3.  Modeling  &  Simulation  (M&S). 

We  plan  to  use  MATLAB/SIMULINK  for  modeling  the  aircraft  handling 
qualities  and  to  develop  acceptable  flight  control  logic  to  aid  in  obtaining  initial  PID 
gains  to  use  in  the  PID  loop  shaping. 

3.3.4.  Test  Limitations. 

A  compressed  test  window  will  be  the  primary  limitation  for  testing.  Testing 
must  be  completed  before  inclement  weather  prevents  testing  at  primary  flight  test  range. 
Testing,  data  reduction,  and  analysis  must  be  completed  in  time  fonn  completion  of 
pertinent  AFIT  master’s  theses,  approximately  March  2012. 

3.4.  Live  Fire  Test  and  Evaluation  Approach.  N/A 

3.4.1.  Live  Fire  Test  Objectives.  N/A 

3.4.2.  Modeling  &  Simulation  (M&S).  N/A 

3.4.3.  Test  Limitations.  N/A 
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3.5.  Certification  for  Initial  Operational  Test  and  Evaluation  (IOT&E).  N/A 

3.6.  Operational  Evaluation  Approach.  N/A 

3.6.1.  Operational  Test  Objectives.  N/A 

3.6.2.  Modeling  &  Simulation  (M&S). 

The  HE-RPA’s  flight  controls  and  propulsion  system  controls  will  be  developed 
in  a  virtual  environment  consisting  of  MATLAB/SIMULINK  in  order  to  generate 
autopilot  parameters.  This  M&S  will  minimize  the  need  for  baseline  airframe 
characterization  and  performance  evaluation  and  minimize  the  overall  risk  associated 
with  flying  a  RPA.  Initial  flight  test  missions  will  be  dedicated  to  verification  of  M&S 
results.  Verification  and  model  and/or  system  modifications  will  be  performed  by  AFIT 
graduate  students. 

3.6.3.  Test  Limitations. 

Flight  testing  must  be  accomplished  prior  to  November  30th  2011  due  to 
anticipated  inclement  weather  conditions  at  test  ranges  and  personnel  availability. 
Contractor  personnel  are  currently  funded  to  support  anticipated  test  timelines. 

Flight  testing  will  be  limited  to  ranges  with  restricted  airspace. 

Flight  test  mission  times  may  be  controlled  and/or  limited  by  parent  organization 
at  test  ranges 

Only  two  test  vehicles  will  be  produced,  potentially  limiting  testing  should  the 
assets  become  unavailable  or  unserviceable. 

Approval  must  be  pre-coordinated  and  granted  by  flight  test  approval  authorities  prior  to 
any  missions. 

3.7.  Other  Certifications. 

Although  official  flight  certifications  and/or  airworthiness  certificates  are  not 
required,  analysis  and  preliminary  test  results  will  be  presented  to  AFIT  and  AFRL 
approval  authorities  as  evidence  of  airworthiness.  Flight  test  approval  will  be  required 
prior  to  each  flight  test  of  the  HE -RPA. 
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3.8.  Reliability  growth. 

No  specific  reliability  growth  testing  is  planned. 

3.9.  Future  Test  and  Evaluation. 

LFT&E,  IOT&E,  and  OT&E  will  not  be  conducted  during  this  portion  of  the  HE- 
UAV  project. 


4.  PART  IV-RE  SOURCE  SUMMARY 
4.1.  Introduction. 

The  resources  necessary  to  facilitate  testing  include  test  labs,  test  ranges,  support 
equipment,  and  government  and  contractor  personnel  support.  All  systems/components 
undergoing  testing  are  considered  to  be  prototypes. 

Test  labs  located  at  AFIT  and  AFRL  will  be  utilized  for  developmental  testing  of  the 
hybrid-electric  propulsion  system,  hardware-in-the-loop  testing,  and  acoustic  testing. 
Propulsion  system  and  airframe  integration  testing  will  also  be  conducted  at  the  AFIT 
labs. 

Full  ground  testing  and  flight  testing  will  be  conducted  at  test  ranges  with  airfield 
access  and  restricted  airspace.  The  primary  flight  test  location  will  be  Camp  Atterbury, 
IN  due  to  its  proximity  and  experience  with  testing  RPAs  and  UAVs.  As  it  is  a  US 
Anny/Joint  training  center,  testing  could  potentially  be  interrupted  to  accommodate  the 
base’s  primary  mission.  Test  procedures  will  be  developed  to  accommodate  these 
possible  interruptions  yet  still  conduct  successful  testing.  A  full  list  of  planned  test  events 
is  included  below. 
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Test  Event 

Test  Location 

Date(s) 

Hybrid-electric  propulsions  system 

developmental  testing 

AFIT  Labs 

Mar  11-Sep  11 

Propulsion  system  integration  testing 

AFIT  Labs 

Aug  11  -  Sep  11 

Flight  control/autopilot  integration  testing 

AFIT  Labs 

Aug-11 

Acoustic  testing 

AFRL  Labs 

Sep-11 

Full  scale  Ground  Testing 

Camp  Atterbury 

31  Aug  2011 -2  Sep  2011 

Aircraft  1  Flight  Testing 

Camp  Atterbury 

31  Aug  2011 -2  Sep  2011 

Backup  dates  for  Flight  Test  of  Aircraft  1 

Camp  Atterbury 

28  Sep  2011  -30  Sep  2011 

Aircraft  2  Flight  Testing 

Camp  Atterbury 

28  Sep  2011 -30  Sep  2011 

Flight  testing  dates  were  chosen  to  best  accommodate  anticipated  system 
availability,  range  availability,  availability  of  contractor  support,  and  to  minimize  the 
impact  of  inclement  weather.  Currently,  backup  dates  for  flight  testing  are  planned  as 
shown. 

4.1.1.  Test  Articles. 

One  primary  hybrid-electric  propulsion  system  will  undergo  developmental, 
hardware-in-the-loop,  and  flight  testing  with  a  possible  second  system  as  a  backup  for 
acoustic  testing. 

Two  aircraft  will  undergo  ground  and  flight  testing.  One  test  article  will  have  and 
ICE  configuration,  the  other  test  article  will  have  a  HE  configuration. 

One  ground  station  will  be  utilized  for  ah  ground  and  flight  testing. 

Ah  test  articles  will  be  considered  prototypes. 
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4.1.2.  Test  Sites  and  Instrumentation. 


All  hardware-in-the-loop  testing  and  a  majority  of  the  ground  testing  will  be 
conducted  in  AFIT  lab.  Acoustic  testing  is  planned  to  be  completed  in  AFRL  labs.  All 
flight  testing  and  some  full  scale  ground  testing  will  be  conducted  at  Camp  Atterbury. 

No  external  instrumentation  will  be  required.  All  necessary  instrumentation  is  self- 
contained  within  the  HE-RPA  system.  Testing  will  be  accomplished  IAW  the  previously 
noted  test  schedule. 

4.1.3.  Test  Support  Equipment. 

Acoustic  testing  will  require  AFRL  provided  recording  equipment. 

Flight  testing  will  require  contractor  support  from  CESE  for  ground  station  setup  and 
manning  and  basic  flight  testing  support  to  include  fuel,  battery  charging,  and  aircraft 
spotting. 

HE-RPA  will  also  require  the  availability  of  GPS  but  its  availability  will  be 
assumed  to  be  present  for  all  testing 

4. 1.4.  Threat  Representation.  N/A 

4.1.5.  Test  Targets  and  Expendables.  N/A 

4.1.6.  Operational  Force  Test  Support.  N/A 

4.1.7.  Models,  Simulations,  and  Testbeds. 

During  DT&E  we  will  use  MATLAB/SIMULINK  for  modeling  the  complete 
system  and  airframe  control  and  performance. 

4.1.8.  Joint  Mission  Environment.  N/A 

4.1.9.  Special  Requirements. 

Preliminary  certification  from  flight  test  approval  authority  is  required  prior  to 
flying  the  HE-RPA.  Additional  funds  and  the  associated  contract  amendment  will  need  to 
be  in  place  should  assistance  from  airframe  developer  be  deemed  necessary  for  flight 
testing. 
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4.2.  Federal,  State,  and  Local  Requirements. 

Flight  testing  will  be  conducted  in  military  controlled  restricted  air  space  to 
ensure  compliance  with  these  regulations  and  restrictions.  As  a  result,  FAA  regulations 
regarding  unmanned  vehicle  operation  will  not  affect  testing. 

4.3.  Manpower/Personnel  and  Training. 

Military,  government,  and/or  contractor  personnel  will  be  involved  in  ah  aspects 
of  testing.  Ah  personnel  will  be  trained  and  certified  on  specific  lab  equipment  as 
needed.  Ah  personnel  conducting  flight  test  operations  at  Camp  Atterbury  will  be 
required  to  complete  Annual  range  safety  training.  Military  personnel  will  develop 
operating  and  training  material  in  conjunction  with  test  plans.  Emergency  and 
contingency  operations  will  also  be  developed  at  that  time.  Ah  testing  will  require  at 
least  one  member  to  act  solely  as  safety  monitor. 

Flight  testing  will  require  the  presence  of  a  support  contractor  trained  and 
authorized  as  a  manually  controlled  safety  pilot. 

No  modeling  and  simulation  will  be  used  or  developed  for  training  purposes. 

4.4.  Test  Funding  Summary. 

The  principle  expense  for  testing  will  be  in  paying  for  contractor  support  and  test 
related  temporary  duty  (TDYs)  expenses.  Funding  will  be  solely  provided  by  AFIT  and 
AFRL  (FY-1 1).  AFRL  funding  will  specifically  be  utilized  for  developmental  testing  of 
the  hybrid-electric  propulsion  system. 
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14.  ABSTRACT 

Today,  Remotely-Piloted  Aircraft  (RPA)  provide  users  with  unique  mission  capabilities,  particularly  on-demand  overhead  surveillance.  However,  a 
capability  gap  has  been  identified  between  the  range  and  endurance  of  RPAs  powered  by  internal  combustion  engines  (ICE)  and  the  reduced  acoustic 
signature  and  smaller  logistical  footprint  associated  with  electric -powered  RPAs.  This  research,  sponsored  by  the  Office  of  the  Secretary  of  Defense,  aims 
at  advancing  systems  engineering  education  by  evaluating  the  utility  of  a  tailored  systems  engineering  approach.  The  tailored  systems  engineering 
approach  used  herein  focuses  on  conducting  a  concept  evaluation  study  on  the  rapid  prototype  development  of  a  parallel  hybrid -electric  RPA  (HE-RPA) 
and  its  ability  to  fill  an  identified  mission  capability  gap.  The  concept  evaluation  utilizes  a  tailored  systems  engineering  process  to  conduct  a  rapid 
prototype  development  and  system  evaluation.  Two  prototype  RPAs  and  a  support  system  are  designed,  integrated,  and  tested  within  a  13  month  time 
window,  in  accordance  with  an  established  architectural  framework.  The  integration  of  a  parallel  hybrid -electric  system  into  an  RPA  demonstrated  a 
potential  reduction  in  acoustic  signature  and  improves  endurance  over  electric  powered  RPAs;  however,  immature  technology  and  added  system 
complexity  result  in  overall  performance  that  is  currently  on  par  with  ICE -powered  RPAs  and  only  partially  satisfies  the  capability  gap. 
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